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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The 3GPP Packet Switch Streaming (PSS) provides a framework for Internet Protocol (IP) based streaming applications 
in by specifying protocols and codecs within the 3GPP system. Protocols for control signalling, capability exchange, 
media transport, rate adaptation and protection are specified. Codecs for speech, natural and synthetic audio, video, still 
images, bitmap graphics, vector graphics, timed text and text are specified. 

The 3GPP Multimedia Broadcast and Multicast Service (MBMS) provides a framework for broadcast and Multicast 
streaming and download applications in 3GPP networks supporting the MBMS bearer service. The MBMS user 
services are enabled by a set of specified media codecs, formats and transport/application protocols. MBMS user 
services are built on top of the MBMS bearer service. There are two delivery methods for the MBMS user services: 
download and streaming. 

The 3GPP IP Multimedia Subsystem (IMS) enables the deployment of IP multimedia applications. PSS and MBMS 
User Services are IP multimedia services but they were specified before IMS. IMS brings enablers and features to 
operators and subscribers that can enhance the experience of PSS and MBMS User Services. 

The purpose of the present document is the specification of use of the IMS to initiate and control PSS and MBMS User 
Service. This should enable deployment of PSS and MBMS user services as IMS services. Note that the present 
specification uses components of the 3GPP PSS, 3GPP MBMS , ETSI TISPAN IPTV and Open IPTV Forum standards 
specifications. 
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Scope 



The present document specifies the usage of IMS protocols to initiate and control PSS and MBMS Streaming User 
Services based applications. It applies to IMS enabled UEs that also implement PSS and/or MBMS clients. Existing 
protocols that are used are described in reference to relevant specifications. IMS based MBMS Download User Services 
are to be defined in a subsequent version of the present document. 

The present document is applicable to IP-based packet-switched networks over 3GPP systems. 

The present document includes information applicable to network operators, service providers and manufacturers 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

On Demand: users can select their required content, for example with the assistance of the Electronic Programme 
Guide (EPG), at the user preferred time. 

NOTE: The content is then transmitted uniquely (unicast) to that consumer who can usually use trick-modes 
functionalities to control their viewing of the content, e.g. TV Content on Demand (CoD) 

IMS registration: registration procedure for a public user identity initiated by the UE in the absence of any valid 
registration 

Live: content is streamed and intended for reception by anyone where the consumer has no control over the content or 
timing of what he receives, apart from the ability to select a particular channel, e.g. linear TV. 
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"Non-IMS" BM-SC: BM-SC function as defined in 3GPP TS 23.246 [5] and 3GPP TS 26.346 [11] without any IMS 
support 

Multimedia Broadcast/Multicast Service (MBMS): See 3GPP TS 22.146 [2]. 

MBMS User Services: MBMS User Service may use more than one Multimedia Broadcast/Multicast Service (bearer 
service) and more than one Broadcast and/or Multicast session 
(See 3GPP TS 22.246 [3].) 

MBMS user service discovery/announcement: user service discovery refers to methods for the UE to obtain the list of 
available MBMS user services along with information on the user service and the user service announcement refers to 
methods for the MBMS service provider to make the list of available MBMS user services along with information on 
the user service available to the UE 

MBMS delivery method: mechanism used by a MBMS user service to deliver content 

An MBMS delivery method uses MBMS bearers in delivering content and may make use of associated procedures. 

MBMS download delivery method: delivery of discrete objects (e.g. files) by means of a MBMS download session 

MBMS streaming delivery method: delivery of continuous media (e.g. real-time video) by means of a MBMS 
streaming session 

MBMS streaming session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the streaming of content 

PSS client: client for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP 
standards, with possible additional 3GPP requirements according to the present document 

PSS server: server for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP 
standards, with possible additional 3GPP requirements according to the present document 

Trick Play: streaming playback mode during which the user can control playback by playing, seeking, pausing, fast 
forwarding and fast rewinding 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

BM-SC Broadcast-Multicast - Service Centre 

ESG Electronic Service Guide 

GGSN Gateway GPRS Serving Node 

IMPI IMS Private Identity 

IMPU IMS Public Identity 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

MBMS Multimedia Broadcast/Multicast Service 

PSS Packet Switch Streaming 

PSI Public Service Identity 

RTP Real-Time transport Protocol 

RTSP Real-Time Streaming Protocol 

SCF Service Control Function 

SDF Service Discovery Function 

SDP Session Description Protocol 

SSF Service Selection Function 

UE User Equipment 

URI Uniform Resource Identifier 

USD User Service Description 
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System description 



4.1 



Introduction 



This clause describes the IMS initiated and controlled PSS and MBMS User Service system. It gives a description of 
the architecture, the role of each new and modified entity and interface. 

The description of the PSS system is in 3GPP TS 22.233 [9] and 3GPP TS 26.233 [10]. The description of the MBMS 
system is in 3GPP TS 23.246 [4]. 



4.2 



Architecture 



4.2.1 Non IMS 3GPP PSS and MBMS User Service architecture 

Figure 1 describes the Non IMS PSS and MBMS User Service architecture. 

Unicast/Multicast/Broadcast Bearers 



PSS and 
MBMS client 












Sources 

Live encoders, 

On demand RIes 


\ 


PSS server 




\ 














/ 


BM-SC 

















Figure 1 : Non IMS PSS and MBMS User Service Architecture 

The sources consist of all multimedia content in streaming or file form. E.g. live encoders processing in feeds from TV 
or Music Radio channels. 

The PSS server performs control and streaming delivery functions on a Unicast access type. 

The BM-SC performs control and streaming/download delivery functions in a hybrid Unicast/Multicast/Broadcast 
access type. 

The core network and RAN enable the mobility, and provides IP connectivity over Unicast/Multicast/Broadcast bearers 
between the servers and the clients. 

The PSS & MBMS client, located in the UE, performs service selection and initiation, receives and present the content 
to the user. 

The PSS client interfaces to the PSS server transparently through the Packet Switch Network. The PSS client can 
discover the PSS services via multiple means like e.g. browsing. The session description protocol is SDP. The session 
control protocol is RTSP. The transport protocol is RTP. 

The MBMS client interfaces to the BM-SC via layer 3 protocols defined between the UE and the GGSN and the GGSN 
with the BM-SC (Gmb). 

The PSS and MBMS client interfaces via the Radio interface to the RAN and the CN. 

The interface between the sources and the PSS server & BM-SC are outside the scope of the present document. 

4.2.2 IMS based PSS and MBMS User Service architecture 

Figure 2 describes the IMS based PSS and MBMS User Service functional architecture. In addition to PSS and MBMS 
User Service functions, the IMS core and various functions are added. 
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Figure 2: IMS based PSS and MBMS functional architecture 

In figure 2: 

• Solid lines are standard interfaces. E.g. interface between PSS server and UE4. 

• Dotted lines are for interfaces for which the protocols in use is out of the scope of the present document. 
E.g. interface between SSF and BMSC.UPF. 

Description of functional entities: 

• IM CN Subsystem: IMS Core Network Subsystem as defined in 3GPP TS 23.228 [6]. The IM CN Subsystem 
supports, user registration and authentication, mobility and roaming, control of multimedia sessions, QoS 
control. Policy control, charging and interworking with circuit switched. 

• EPC/PS Core/RAN: Evolved Packet Core, Packet Switch Core Network and Radio Access Network. See 3GPP 
TS 23.060 [16] and TS 23.401 [30]. 

Note: the various packet core networks may offer different levels of support (e.g. the EPC does not support 
MBMS in 3GPP Release 8). 

• UE: The UE contains an GBA/IMS/PSS/MBMS client, which performs service discovery and selection, handles 
service initiation, modification and termination, receives and present the content to the user. In addition to the 
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procedures specified in this document, the UE shall support the procedures specified in 3GPP TS 24.229 [7] for 
the UE functional entity. 

• SDF: Service Discovery Function (SDF): this function provides an entry point to SSF for the client to attach to 
the service provided by the service provider. In addition to the procedures specified in this document, the SDF 
shall support the procedures specified in 3GPP TS 24.229 [7] for the terminating UA functional entity. 

• SSF: Service Selection Function (SSF): this function provides a list of available PSS and MBMS User Services 
and relevant User Service Description information. It can be personalized to the client's identity. The SSF shall 
support Service Announcement functions according to the Xa interface in TISPAN. The PSS portal is for 
formatting and delivery of PSS Service Description information. The BMSC.IAF and BMSC.USD/A functions 
are according to 3GPP TS 26.346 [11]. The interface between BMSC.IAF and UE is according to 

3GPP TS 26.346 [11] and out of the scope of the present specification. If the User Service Description 
information exists in a BMSC.USD/A of a "Non-IMS" BM-SC, or in a PSS portal, the SSF takes USD 
information from them. The SSF may then reformat the USD information before delivery to the UE. The 
reformat may include information for the IMS UE to build a SIP URI to initiate PSS and MBMS user service. 

• SCF: Service Control Function (SCF): it provides service logic and functions required to support execution of 
such logic. It does service authorization during session initiation and session modification, which includes 
checking PSS and MBMS user's service subscription in order to allow or deny access to the service. It selects the 
relevant PSS and MBMS media functions. In addition to the procedures specified in this document, the SCF 
shall support the procedures specified in 3GPP TS 24.229 [7]: 

• For PSS, the SCF acts as a proxy or B2BUA. 

• For MBMS, the SCF acts as a terminating UA. 

• BSF: Bootstrapping Server Function (BSF) as defined in 3GPP TS 33.220 [26] to perform GBA/GAA 
procedures with the UE. 

• HSS: Home Subscriber Server as defined in 3GPP TS 23.002. Contains the IMS User Profile. It also may 
contain PSS and MBMS User Service specific User and UE data. 

• PSS Adapter: this function performs bi-directional protocol translation between SIP and RTSP to offer control of 
PSS servers as defined in clause 8.2.3.5. It proxies RTSP messaging from the UE and SIP/RTSP translation 
towards the PSS server. Note that these functions can be incorporated into the SCF, the PSS Server or a new 
stand-alone entity. In addition to the procedures specified in this document, the PSS Adapter shall support the 
procedures specified in 3GPP TS 24.229 [7] for the terminating UA functional entity. 

• PCRF: Policy and Charging Rules Function (3GPP TS 23.203 [12]). This function controls the charging and the 
establishment of resources in the RAN and PS core network. 

• PSS Server: Packet Switch Streaming server function as described in 3GPP TS 26.234 [8]. It functionally 
contains media control and media delivery functions. 

• BMSC.UPF: it contains all BMSC User Plane sub-functions. 

NOTE 1: The BM-SC Membership function and Proxy and Transport function are defined in 3GPP TS 23.246 [4]. 
These functions are not described on the architecture in figure 2. The BM-SC Membership function is 
invoked for the establishment and release of Multicast bearers. 

Description of interfaces: 

The interface between the UE and the SSF is used to retrieve service selection information. It is part of the SGi/Gi 
interface and based on HTTP protocol. 

Gm: This is a SIP based interface between the UE (IMS Client) and the P-CSCF. It is used to forward the SIP service 
request and response between UE and network. 

The interface between the UE (PSS Client) and the PSS Adapter allows media flow control. It is part of the SGi/Gi 
interface and based on RTSP protocol. 

The interface between the PSS Server and the UE is for delivery of streaming data. It is part of the SGi/Gi interface and 
based on RTP and RTCP protocols. 
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The interface between the BMSC.UPF and the UE is for delivery of streaming data and traffic keys. It is part of the 
SGi/Gi interface and based on (S)RTP, FLUTE and MIKEY protocols. 

Gmb: This interface is between the BMSC.UPF and the GGSN. The Gmb interface is defined in 3GPP TS 23.246 [4]. 

The interface between the PSS Adapter and the PSS Server allows control of the PSS Server. This interface is based on 
RTSP protocol. 

NOTE 2: This interface needs to be named. 

The interface between the IM CN subsystem and the SCF is an ISC (IMS Service Control) interface based on SIP. The 
interface between the IM CN subsystem and the PSS adapter is an interface based on SIP protocol.. Both interfaces are 
used to setup, modify and teardown PSS sessions. 

NOTE 3: Under certain conditions this interface between the SCF and the PSS adapter can be implemented as a 
direct interface (i.e. not going via the IM CN subsystem). 

NOTE 4: The interface between the IM CN subsystem and the PSS adapter needs to be named. 

This interface between the SSF and the BMSC.UPF is according to 3GPP TS 26.346 [1 1]. It may be used to carry USD 
over MBMS bearers. 

The interface between the SDF and the IM CN subsystem is an ISC (IMS Service Control) interface based on SIP 
protocol. 

The interface between the UE and SCF is used for PSS and MBMS User Service and User Profile configuration. It is 
equivalent to the Ut interface in TISPAN IPTV. 

The interface between the SCF and the BMSC.UPF is used for security related functions and is FFS. 

The interface between the SCF and the PSS Server is FFS. 

The interface between the UE to the BMSC.SnTF is used for MBMS Associated Delivery procedures as defined in 
3GPP TS 26.346 [11]. It is part of the SGi/Gi interface. 

The interface between the UE and the BMSC.KF is used for delivery of the MSK as defined in 3GPP TS 26.346 [1 1]. It 
is part of the SGi/Gi interface and based on MIKEY/UDP protocols. 

The interface between the UE and the BMSC.KF is used for Key Request Functions and is FFS. 

NOTE 5: This interface will be clarified based on agreed security procedures. 

4.3 IMS based PSS and MBMS US procedures overview 

Figure 3 describes the IMS based PSS and MBMS procedures from connection establishment to User Service 
Description retrieval. 
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Figure 3: Procedures overview - part 1 

Step 1 to 3: are outside the scope of the present document. 

Step 4: Service discovery, allows the Client to be informed of the available Service Providers. 

Step 5: GBA/GAA bootstrapping procedures, authenticates the User for signalling outside IMS and 

generates the Long Term Key that will be used during content key management procedures. 



Step 6: 
Figure 4 describes the IMS based PSS and MBMS procedures from session establishment to content key management. 



Retrieval of User Service description, allows the client to obtain the service session information 
for the selected provider. 
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Step 7: 
Step 8: 



Figure 4: Procedures overview - part 2 

Session Establishment, allows the Client to initiate a PSS or MBMS User Service session to 
receive content. 

Policy and Charging Control, are procedures performed via the IMS core to setup relevant bearer 
QoS and charging functions. 
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Step 9: Content Key Management is necessary to generate and distribute the keys to allow secure delivery 

of content to the User. At this stage, the delivery session is established and content is delivered to 
the client. 

4.4 PSS and MBMS user profile and UE capabilities 

4.4.1 User profile description 

The PSS and MBMS user profile data contains all information required to operate PSS and MBMS user services. 

The part of the PSS & MBMS user profile used for On Demand (CoD in TISPAN) and Live (BC in TISPAN) services 
shall be as defined in TISPAN TS 183 063, Annex C. 

4.4.2 UE capabilities 

A set of PSS and MBMS UE capabilities is required to personalize and operate PSS and MBMS user services. These 
capabilities are described in 2 documents: 

• The PSS and MBMS UE CapabiUties XML document defined in Annex G. 

• The RDF/XML document for the PSS base vocabulary specified in Annex F of TS 26.234 [8]. 
These 2 documents are sent during the Service Discovery procedure. See clause 6. 

4.4.3 Storage location 

PSS and MBMS user profile and UE capabilities information may be stored in the following locations: 

• Application Server functions. 

• In a stand-alone server associated with one or more Application Server functions. 

• In the HSS as transparent data associated to these Application Server functions. 

The first and second options are recommended for data to be accessed by 3rd party application server functions. In the 
first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an XDMS. 

User data stored in the HSS can be accessed by Application Servers at the Sh reference point. 

A subset of PSS and MBMS user-profile information may be accessed from the User Equipment at the Ut reference 
point. 

For the purpose of personalized service selection, the SSF may need to access user data. 

In the case when such user data is stored in the HSS, it can be accessed by the SSF at the Sh reference point when the 
SSF is in the same domain. 

On the contrary, when such user data is stored in the AS or in a stand alone server associated with one or more 
application servers or if the SSF in not in the same domain as the HSS, the user data can be accessed by the SSF using 
an interface that is out of scope for this release. 

The SSF may also request notification of user data updates. 
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5.1 



Service Provider Discovery 



Introduction 



In order for the UE to access the PSS and MBMS User Service using IMS, it shall implement an IMS client that 
registers to the IM CN Subsystem [7]. This assumes that the UE has attached to a network and established PS 
connectivity through a PDF context according to 3GPP TS 23.060 [16] and has successfully completed the P-CSCF 
discovery procedure [7]. Once the UE is registered to the IM CN Subsystem, it can proceed to the Discovery of the PSS 
and MBMS User Service. 

This clause specifies how the UE performs the PSS and MBMS Service Provider Discovery. This is equivalent to 
discovering the list of IMS PSI of the SDF and relative Service Providers. There are several means for the UE to 
acquire this information. The UE shall implement the DNS based Service Provider Discovery as defined in clause 5.2. 
Other methods are optional. 



5.2 



DNS 



In this case, the SDFs are discovered using the DNS SRV mechanism in accordance with RFC 2782 [17], with the 
following input parameters: 

• Service: Defined as "pss-mbms-user-service". 
NOTE: to be registered with IAN A. 

• Protocol: Can take values "http" or "sip". Specifies the protocol to contain the particular service. 

• Domain name: the domain for which the returned records are valid. The value can be derived from the ISIM. 
Without ISIM it can be derived from USIM together with MCC (Mobile Country Code) and MNC (Mobile 
Network Code) according to TS 23.003 [29]. If not possible, the domain name can be derived from network 
attachment phase (DHCP server). Manual configuration overrides these possibilities. 



UE 



PS core/RAN 



DNS server 



DNS query 



DNS Reply 



Figure 5: Service Provider Discovery withi DNS 

The output of the DNS SRV lookup is an ordered list of domain name, each pointing to a SDF server available within 
the specified Domain name. 

5.3 Others 

Alternatively, the SDF PSI may also be signalled to the UE by the following means: 

• Manually provisioned in the UE. 

• OMA Device Management. 

• SMS. 

• OMA Push. 

• MBMS. 
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6.1 



User Service Discovery 



Introduction 



This clause specifies how the UE performs the PSS and MBMS User Service Discovery. This is equivalent to 
discovering the address of the SSF. 



6.2 Subscribe/Notify 
6.2.1 General description 
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Figure 6: Service Discovery withi Subscribe/Notify 

1) The UE sends a SIP SUBSCRIBE message to the IM CN subsystem. It should indicate its capabilities in the 
message. 

2) The IM CN subsystem forwards the request to the SDF, e.g. thanks to an iPC. 

3) The SDF determines the proper service discovery information, e.g. according to the UE capabilities, the user's 
profile (Personalized Service Discovery). The user profile may be retrieved from the HSS or any other entity 
where it is stored. 

4) The SDF sends a SIP 200 OK response to the IM CN subsystem, which forwards it to the UE. 

5) The SDF sends a SIP NOTIFY message to the UE, with service discovery information that includes the SSF(s) 
address(es). 

6) The IM CN subsystem relays the SIP NOTIFY message back to the UE, with the service discovery information 
related to PSS and MBMS user service. 

7) The UE sends back a SIP 200 OK response to the IM CN subsystem. 

8) The IM CN subsystem forwards the SIP 200 OK to the SDF. 
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6.2.2 Procedures at the UE 

6.2.2.1 Introduction 

The UE shall generate a SUBSCRIBE request. The behaviour of the UE when processing a SUBSCRIBE request shall 
conform to 3GPP TS 24.229 [7]. 

6.2.2.2 Subscription 

When the UE intends to retrieve service attachment information from the SDF, it shall generate a SUBSCRIBE request 
for the "ua-profile" event package defined in [28] and extended as described in [18]. 

The contents of the SUBSCRIBE request shall be as follows: 

• The value of the Request-URI shall be set to one of following: 

the PSI of the SDF which is retrieved using SDF Discovery procedures in clause 5 Service Provider 
Discovery; or 

the public user identity of the end user (when the UE does not know the PSI of the SDF). 

• The From and To header shall be set to the public user identity of the user. 

• The Accept header shall include the content-type identifier that corresponds to the registered MIME type of 
XML documents representing UE capabilities included in the body, See clause 4.4.2: 

• A first Content Type set to "application/3gpp-ims-pss-mbms-ue-capabilities+xml". 

• A second Content Type set to "application/rdf+xml". 

• The Event header shall be set to the "ua-profile" event package. 

• The Event parameters shall be set as follows: 

The "profile-type" parameter shall be set to "application". 

The "vendor", "model" and "version" parameter values shall be set to values specified by the implementer of 
the user equipment, as specified in 3GPP TS 24.229 [7]. 

The "appids" parameter shall be present and set to "urn:org:3gpp:applications:ims-pss-mbms-service- 
discovery". 

The UE shall include a SIP SUBSCRIBE multipart/mixed content-type message body associated with the appid 
including the PSS and MBMS UE Device Capabilities defined in Annex G and the RDF/XML document describing the 
PSS base vocabulary defined in Annex F of TS 26.234 [8]. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

The UE shall automatically refresh the subscription, either 600 seconds before the expiration time if the initial 
subscription was for greater than 1 200 seconds, or when half of the time has expired if the initial subscription was for 
1 200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall 
still consider the original subscription valid for the duration of the most recently known "Expires" value according to 
3GPP TS 24.229 [7]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription 
according to 3GPP TS 24.229 [7]. 

6.2.2.3 Receiving notifications 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the application within the 
UE shall parse the XML document contained in the message body. The XML document schema is defined in Annex H. 

The list of parameters in the XML document shall be used for service selection information retrieval according to 
clause 7. 
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After all elements have been processed, the UE shall return a 200 OK response to the NOTIFY request. 

Failure to perform subscription refresh does not imply that there is a loss of communication to SSF or SCF. The UE has 
an option to continue using the lists of parameters from the last NOTIFY. 

After deregistration, the UE may keep stored information on per user basis. As for subscription refresh, the UE may use 
the stored information if initial subscription fails after a new registration. 

6.2.3 Procedures at the SDF 

The SDF addresses are determined by the UE using any of the alternatives as defined in clause 5. 

When the SDF receives a SUBSCRIBE request, it may perform user's identity verification as defined in 
3GPP TS 24.229 [7]. After successful user identification, if a User Profile is available it is possible to perform 
personalization of the body (Service Attachment Information) of the NOTIFY request. 

The SDF shall examine the parameters specified in the SIP SUBSCRIBE body and shall then record UE capabilities 
information as part of the user profile data. 

NOTE: The UE capabilities that are recorded as part of the user profile may be used by the SSF for 
personalization purposes. 

In case of successful subscription, the SDF shall generate a SIP 200 OK in response to the SUBSCRIBE request. The 
SDF shall then send a NOTIFY request immediately. 

The contents of the NOTIFY request shall be as follows: 

• The Event header shall be set to the "ua-profile" event package. 

• The "effective-by" parameter for the event header shall be set to 0. 

• The content type shall be set to "application/Sgpp-ims-pss-mbms-service-discovery+xml"; 

• The message body shall contain an XML document listing SSF addresses and the means of connecting to the 
SSFs for retrieving service selection information defined in Annex H. The "©technology" element name 
indicates the technology used to for delivering service selection information. It shall be set to the 
"openmobilealliance.org_bcast" . 



7 User Service Description retrieval 

7.1 Introduction 

User Service Description retrieval can be done in several ways 

By retrieving OMA BCAST Service Guide information [27] from the SSF. See clause 7.2; 

By retrieving MBMS USD from the SSF as defined in 3GPP TS 26.346 [11] clause 5.2; 

By executing the Procedure for providing missing parameters before session initiation described in 
clauses 8.2.2 and 8.3.2 for PSS and MBMS user service respectively. 
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7.2 User Service Description retrieval for PSS and IVIBIVIS 

7.2.1 Procedures at the UE 

7.2.1 .1 Procedure for Service Personalisation 

For HTTP-based data retrieval, when sending the HTTP request to the SSFs, the UE may provide personalized 
information to enable a personalized answer. This shall be done by adding the X-3GPP-Intended-Identity HTTP header 
to the request to transmit the public identity. 

The authentication shall follow 3GPP TS 33.222 [20]. 

The UE shall implement Transport Layer Security (TLS), as described in 3GPP TS 33.222 [20]. 

7.2.1 .2 Request of OMA BCAST ESG 

In the pull model of unicast delivery of an OMA BCAST ESG, the HTTP protocol shall be used conforming to OMA 
BCAST Service_Guide [27], clause 5.4.3. 

7.2.1 .3 Use of Service Description information 

The UE shall use parameters received from the SSF for session initiation. 

NOTE: There is no restriction on the UE to use any parameter received from SSF also for other purposes than 
session initiation, e.g. to present SSF information to the user. 

The UE may store a part of the ESG information covering certain period of time and refresh this information 
periodically This avoid the UE to contact the SSF every time the user needs to consult the ESG. 

If the UE is unable to contact any discovered SSF, it shall not delete stored information immediately. 

7.2.2 Procedures at the SSF 

7.2.2.1 Authentication and authorisation in case of personalized service description 
information 

In case of service selection personalisation the SSF shall authenticate the user. 

The authentication shall follow 3GPP TS 33.222 [20]. 

The SSF shall implement Transport Layer Security (TLS) as described in 3GPP TS 33.222 [20]. 

An authentication proxy (AP) may exist between the UE and the SSF in which case the behaviour of the AP is assumed 
to conform to 3GPP TS 24.423 [21]. 

If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the SSF receives an HTTP request 
from a trusted source (the AP) and the request contains an HTTP X-3GPP-Asserted-Identity header 
(3GPP TS 24.109 [22]) that includes an asserted identity of the user. In this case the SSF does not need to authenticate 
the user, but just provide authorization to access the requested resource. 

If an HTTP X-3GPP-Asserted-Identity header (3GPP TS 24. 109 [22]) is not present in the HTTP request or if the 
request is received from a non-trusted source, then the SSF needs to authenticate the user prior to providing personalise 
information by applying the procedures defined in 3GPP TS 33.222 [20] and 

authorize or deny authorization depending on the authenticated identity. 

7.2.2.2 Procedure for Service Personalization 

If the public user identity information is present in the query from the UE, the SSF shall extract it to 
customize/personalize the service information that is returned in the query response. 
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The SSF shall use the public user identity that is specified in the X-3GPP-Intended-Identity header or the 
X-3GPPAsserted-Identity header if an authentication proxy is used to fetch the corresponding user profile associated 
with the user. For instance, the Parental Control (if present) should be used to remove unsuitable elements from the 
COD listings that are returned to the UE. 

7.2.2.3 Delivery of OMA BCAST ESG 

The procedure for retrieving OMA BCAST service selection information is employed to retrieve one or more Service 
Guide Delivery Descriptors (SGDD) and/or Service Guide Delivery Units (SGDU). The SGDD describes service level 
information as well as access information to the Service Guide fragments. The SGDU is the transport-independent 
network structure for encapsulating Service Guide fragments. 

When the ESG SSF receives a HTTP POST request, if personalization headers are presents (in the form of key-value 
pairs) it shall use those headers in order to build a personalized response. For instance, the ESG SSF may use the 
provided user identity to retrieve the associated Parental Control Level in the user profile. This Parental Control Level 
would then be used to remove non suitable elements from the ESG data that are sent back. The provided user identity 
may also be used to retrieve a personalized ESG using the method in OMA BCAST Service Guide [27], 
clause 5. 4. 3. 3. The ESG SSF shall send an HTTP response conforming to OMA BCAST Service Guide [27], clause 
5.4.3. L The body of the HTTP response shall contain an XML document with SGResponse data, conforming to OMA 
BCAST Service Guide [27], clause 5.4.3. LI. 



8 Streaming session and media control 

8.1 General 

This clause specifies the procedures and protocols used for the IMS based initiation and control of streaming sessions 
on PSS or MBMS User Service. 

The client shall use SIP to initiate and control PSS and MBMS streaming sessions. Once a PSS streaming session is 
established, the client shall use RTSP protocols to perform media control. 

8.2 PSS Streaming 

8.2.1 PSS Media codecs and formats 

PSS Media codecs and formats defined in 3GPP TS 26.234 [8] are applicable to the present document for IMS initiated 
and controlled PSS services. 

8.2.2 Procedure for providing missing parameters before session initiation 
8.2.2.1 Procedures at the UE 

If the UE does not have all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS message: 

• The "Request-URI" is related to the PSS session that the user wants to activate. The Request-URI shall be 
composed of a user and domain part as defined as follows: 

The user part contains the content identifier, retrieved from user service description information from SSF. 

The domain part is the Service Provider domain name, obtained from SSF. 

• The TO header shall contain the same URI as in the "Request-URI" parameter. 
The other headers shall be set according to TS 24.229 [7]. 

Upon reception of the 200 OK including SDP, the UE shall initiate PSS session as described in clause 8.2.3. 
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8.2.2.2 Procedures at the SCF 

When receiving the SIP OPTIONS message, the SCF shall select the appropriate PSS Adapter and forward the SIP 
request to the appropriate PSS Adapter by changing the "Request-URI" accordingly. 

The SCF shall not change the user -part of the TO header in order to keep the content-id in the OPTIONS request. 



8.2.2.3 



Procedures at the PSS Adapter 



When receiving SIP OPTIONS request, the PSS Adapter shall examine the On Demand content identifier present in the 
user -part of the TO header. 

If the PSS adapter does not have the user service description information, it shall send an RTSP DESCRIBE message to 
the PSS server to retrieve the user service description information 

Then, the PSS Adapter shall answer with the user service description information of the content delivery channel in 
SDP as requested by the request URL 

8.2.3 PSS Streaming Session initiation 
8.2.3.1 General description 
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Figure 7: IMS based PSS initiation 

NOTE 1: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
the UE in response to the reception of 200 OK. 

NOTE 2: SIP messages between PSS adapter and SCF go through the IM CN Subsystem even if not indicated on 
the sequences. 

8.2.3.2 Procedures at the UE 

The UE shall generate an initial INVITE request according to TS 24.229 [7] with the following additions: 
• The Request-URI is related to the PSS session that the user wants to activate. 

• For an On Demand service, it shall be composed of a user part and a domain part, as follows: 
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• A user part containing the content identifier in a free string format. 

• A domain part containing the content provider domain name, obtained from the SSF. 
• For Live content, it shall contain the PSI (Public Service Identity) of the " Live stream". 

• The To header shall contain the same URI as in the Request-URL 

The other headers shall be set according to TS 24.229 [7]. 

An SDP Offer shall be included in the initial INVITE request, in accordance with media capabilities and policies 
available for the PSS session and with the parameters received from the SSF during service selection procedure. 

The SDP offer shall contain a media description for the RTSP content control channel and one for the content delivery 
channel. The RTSP content control media description shall be carried by TCP. 

The SDP parameters for the RTSP content control channel shall be set as follows: 

• a 'm' line for an RTSP stream of format: m=<media> <port> <transport> <fmt> 

The media field shall have a value of "application". 

- The port field shall be set to a value of 9, which is the discard port. See RFC 4145 [13] and RFC 4572 [14]. 

The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of 
TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. 

The <fmt> parameter shall be included and shall be set to 3gpp_rtsp. 

NOTE: the 3gpp_rtsp application format should have a new MIME subtype registered in IAN A. 

An "a=setup" attribute shall be present and set to "active" indicating that the UE will initiate an outgoing 
TCP connection to the PSS Adapter [7] and [13]. 

An "a= connection" attribute shall be present and set as "new" " indicating that the UE will establish a new 
outgoing TCP connection towards the PSS Adapter [7] and [13]. 

A "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related RTSP content control (ex. c=IN IP4 <IP_ADDRESS>). 

Example of RTSP "m' line offer from the UE: 

m=application 9 TCP 3gpp_rtsp 
C=IN IP4 192.0 .2.2 
a=setup : active 
a=connection : new 

For each media stream controlled by the RTSP content control channel, the SDP offer shall include a "receiver only" 
content delivery channel media description set as defined in 3GPP TS 26.234 [8], clause 5.3.3: 

• the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery 
channel. It may also include a fmt parameter which shall indicate the format given by the SSF or by executing 
the procedure for providing missing parameters before session initiation described in clauses 8.2.2, a subset of 
them or the format offered by the UE if none is given by the SSF; 

• the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow of the related content delivery channel; 

(ex. c=IN IP4 <IP_ADDRESS>) 

• optionally a "b=" line may contain the proposed bandwidth. If the user has fetched the bandwidth required for 
this particular content delivery channel during service selection retrieval, the bandwidth attribute at media level 
shall be set to this value. Otherwise, this attribute shall be set to a pre-configured value; 

(ex. b=AS: 15000) 

• A "a=" line with a "recvonly". 

The UE should receive a SIP 200 OK back containing the final SDP. 
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8.2.3.3 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.3.4 Procedures at the SCF 

Upon receipt of SIP INVITE request, the SCF shall examine the Request-URI and SDP parameters to determine that it 
is a PSS session initiation request for Live Streaming or Content-On-Demand. According to the user subscription 
information, the SCF shall check the service rights of the requested PSS service. 

If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the SCF 
determines that the PSS streaming session is initiated for On Demand content. In this case, the SCF shall select a 
suitable PSS adapter and forwards the SIP INVITE to the selected PSS adapter by changing the Request-URI 
accordingly. The SCF shall not change the user part of the To header in order to keep the content identifier in the 
INVITE request. 

When receiving a 301 or 302 response from the PSS adapter, the SCF shall not forward this message to the UE. It may 
check if the PSS adapter indicated in the Contact header belong to allowed destination. If allowed, the SCF shall use 
one of the PSS adapter URI indicated in the Contact header of this response and use it as a destination for the redirected 
INVITE. 

If the request-URI contains the PSI " Live Stream", the SCF determines that the PSS streaming session is initiated for 
Live content. In this case, the SCF shall select a suitable PSS adapter and forwards the SIP INVITE to the selected PSS 
adapter. The SCF shall include the list of authorized Live content channels for the user in the SIP INVITE transmitted 
to the PSS adapter by including the package identifiers containing to the list of authorized Live content channels for the 
session and optionally transmitting the list of authorized RTSP URIs. 

Based on the Request-URI and SDP parameters, the SCF selects a suitable PSS Adapter and forwards the SIP INVITE 
to the selected PSS Adapter. 

Once receiving a SIP 200 OK response from PSS Adapter, the SCF shall forward the response to UE. 

8.2.3.5 Procedures at the PSS Adapter 

The PSS Adapter shall be statefully aware of any sessions between the PSS Adapter and a UE, and the PSS Adapter and 
the PSS Server related to the same streaming session . This means that the RTSP session between the PSS Adapter and 
the PSS Server and the SIP & RTSP sessions between the PSS Adapter and the UE are associated at the PSS Adapter in 
order to keep session structure and alignment. This includes, but is not limited to, RTSP parameters such as sessionid, 
IP version, CSeq, etc. 

The PSS Adapter shall support the following RTSP methods for PSS Server session establishment and teardown 
control: 

• DESCRIBE (PSS Adapter to PSS Server). 

• SETUP (PSS Adapter to PSS Server). 

• TEARDOWN (PSS Adapter to PSS Server). 

The PSS Adapter should support the "3gpp-pipelined" feature so as to be able to pipeline SETUP messages. 
Upon receipt of a SIP INVITE message, the PSS Adapter performs the following actions: 

• It shall resolve the RTSP URI based on the R-URI, the SDP parameters and the selected PSS Server. 

• It may send a DESCRIBE message to the PSS Server to fetch the SDP file. 

• It shall construct and send the RTSP SETUP message(s) to setup the relevant media streams. 

• Return the final SDP to the UE in the SIP 200 OK. 

The PSS Adapter shall construct the RTSP SETUP message according to the SIP Invite as follows: 

• The Request-Line shall be present of format: Request-Line = Method SP Request-URI SP RTSP- Version CRLF: 
- Method field is set to SETUP; 
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- RTSP- Version field to be set of RTSP/1 .0. 

• The CSeq header field is set to a value allocated by PSS Adapter according to RFC 2326 [25] 

• The transport header field: 

the protocol and profile sub-fields together are set to a value of the protocol sub-field of the corresponding 
"m=" hne in the SDP offer, 

the unicast I multicast parameter is set to unicast. 

The destination parameter is set to a value of the "c=" line of the corresponding media delivery channel in 
the SDP offer, 

The RTP port value of client_port parameter is set to the value of the port sub-field of the corresponding 
"m=" line in the SDP offer, and the RTCP port value of client_port parameter is set to a value of the RTP port 
value plus 1 . 

An example of the RTSP SETUP message is: 

PSS Adapter->PSS Server: SETUP rtsp://media.example.com/movie001/audiotrack RTSP/1 .0 

CSeq: 1 

Transport: RTP/AVP/UDP; unicast; destination=<IP ADDRESS>; client j)ort=3400-3401 
The PSS Adapter may send multiple RTSP SETUP messages if multiple media delivery channels are carried within the 
SDP offer. In this case, the pipeline of multiple RTSP SETUP messages may be supported. 

When receiving a RTSP 200 OK response from the PSS Server, the PSS Adapter parses the response, constructs a SIP 
200 OK response with the final SDP, and sends the SIP 200 OK response to the SCF. The final SDP shall describe the 
RTSP session established by the PSS Adapter and the TCP connection to be established by the UE. 

The PSS Adapter shall construct the SIP 200 OK message according to RTSP 200 OK as follows: 

• an 'm' line for an RTSP stream of format: m=<media> <port> <transport> <fmt> 

The media field shall have a value of "application". 

The port field shall be set to the value allocated by PSS Adapter for the UE to establish RTSP session, such 

as 554. 

The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of 

TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. 

• a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP address 
of PSS Adapter for the flow of the related RTSP content control (e.g. c = IN IP4 <IP_ADDRESS>). 

• The "setup" attribute is set to 'passive' indicating that connection shall be initiated by the other endpoint (UE). 

• An "a= connection" attribute shall be present and set as "new" indicating that the UE will establish a new outgoing 
TCP connection towards the PSS Adapter [7][13]. 

• An "a=control" attribute shall be present in the format of an absolute URI to be used for the UE in the subsequent 
RTSP requests. 

• One or more a=fmtp lines representing RTSP specific attributes set as follows: 

a "fmtp:3gpp_rtsp h-session" attribute representing the session identifier for the RTSP session to be 
established with the UE. 
The PSS Adapter may include "fmtp: 3gpp_rtsp h-offset" attribute that indicates where the playback is to start from. 

Example of RTSP "m' line answer from the PSS Adapter: 

m=application 554 TCP 3gpp_rtsp 

c=IN IP4 192.0.2.1 

a=setup ipassive 

a=connection : new 

a=control : rtsp : //example . com/channel/contentl . sdp 

a=fmtp 3gpp_rtsp h-session=12345 

a=fmtp 3gpp_rtsp h-offset=30 

For each media stream controlled by the RTSP content control channel, the SDP answer shall include a content delivery 
channel media description set as follows: 

• the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery 
channel. 
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The port value shall be set to the RTP port value retrieved from the server_port parameter in the RTSP 200 OK 

message. 

If an fmt parameter is in the SDP offer it shall be completed with the supported format by the PSS Server; 

the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and the 
unicast address of the PSS Server for the flow related to the content delivery channel, 
(ex. c=IN IP4 <IP_ADDRESS>); 

the "b=" line shall contain the proposed bandwidth. Since the PSS media stream is unidirectional the bandwidth 
shall be set to 0, except for the case that the transport is RTP and RTCP is allowed, 
(ex. b=AS:0); 

an "a=" line with a value of "sendonly". (ex. a=sendonly). 



8.2.4 PSS Streaming Playback Control 
8.2.4.1 General Description 



UE 



RTSP PLAY 



RTSP 200 OK 



RTP 



PSS Adapter 



PSS Server 



RTSP PLAY 



RTSP 200 OK 



Figure 8: Initial Payback 

8.2.4.2 Procedures at the UE 

The UE shall support the following RTSP methods for RTSP playback control: 

• PLAY (UE to PSS Adapter). 

• PAUSE (UE to PSS Adapter). 

• GET_PARAMETER (UE to PSS Adapter). 

• SET_PARAMETER (UE to PSS Adapter). 

• OPTIONS (UE to PSS Adapter). 

When receiving any SIP response, the UE shall examine the media parameters in the received SDP: the UE shall 
immediately setup the TCP connection carrying RTSP. The UE shall fetch the RTSP session ID from the SDP answer 
contained in the SIP response. This RTSP session ID shall be used for RTSP media control messages. 

After SIP session establishment, the UE can exchange RTSP messages to start to receive media streams. The UE shall 
send an RTSP PLAY message to the PSS adapter according to 3GPP TS 26.234 [8]. 

• The RTSP URL shall be set to the value retrieved from the SDP "a=control" attribute in the case of an absolute 
URL If the value of "a=control" is a relative URI that is in the form of a media path, then the RTSP absolute 
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URL is constructed by the UE using the SDP IP address (from c-line) and port (from m-line) as the base 
followed by "a=control" value for the media path. 

• The RTSP session ID in the h-session received in the SDP shall be used in RTSP media control messages. 

• The version attribute shall be present in the SDP and its value shall be 1 .0 in this version of the specification. 



• 



If the h-offset attribute is present in the SDP, the Range parameter in the first RTSP PLAY message may be set 
to its value. E.g. Range: npt=<OFFSET>- (with OFFSET being the value of the h-offset attribute). 



8.2.4.3 Procedures at the PSS Adapter 

If the PSS Adapter supports the proxying of RTSP towards the PSS Server then the following methods shall be 
supported: 

• PLAY; 

• PAUSE; 

• GET_PARAMETER; 

• SET_PARAMETER; 

• OPTIONS. 

Upon receipt of a RTSP message from an UE, the PSS Adapter shall match the RTSP session with the RTSP sessions 
once established with PSS Server according to the Session ID carried in the received RTSP message. If there is a 
session match, PSS Adapter shall send the RTSP message to PSS Server on the matched RTSP session. If no session 
matches, PSS Adapter shall response with a RTSP error code 454 (Session Not Found). 

When receiving a RTSP response message from a PSS Server, the PSS Adapter shall match the RTSP session with the 
RTSP sessions once established with UEs according to the Session ID carried in the received RTSP response message, 
and send the RTSP response message to UE on the matched RTSP session. 

The PSS Adapter should send a SIP INFO message to the SCF indicating that playback has started. This SIP INFO 
message should be equal to the SIP INFO messages for PSS content switching defined in clause 8.2.5. 

8.2.4.4 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.2.5 PSS content switching 

8.2.5.1 PSS Streaming session modification 

8.2.5.1.1 General description 

NOTE 1 : The specification assumes the UE will trigger a Re-INVITE procedure to change the QoS to fit the new 
channel requirements. It will be considered whether the network can trigger the QoS change without the 
UE taking management. 

This procedure presents the generic PSS streaming session modification procedure. It can be referred in some cases for 
PSS Content Switching, when there is a change of media components and/or bandwidth. 
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Figure 9: UE-initiated PSS session modification 

NOTE 2: Like in other call-flows of the specification, the figure does not show that messages exchanged between 
the PSS adapter and the SCF are routed through the IM CN subsystem. 

1) The UE sends the Re-INVITE request containing the SDP offer to the IM CN Subsystem to establish the 
content delivery channel. The IM CN Subsystem may require the PCRF to reserve additional resources for 
RTP streams according to the SDP in the Re-INVITE. The IM CN subsystem may also issue the PCRF to 
release resources for RTP streams. 

2) The IM CN Subsystem forwards the Re-INVITE request to the SCF. 

3) The SCF sends the Re-INVITE to the PSS adapter via the IM CN Subsystem. 

4) The PSS adapter sends the according number of RTSP SETUP to the PSS server, if additional media 
components are described in the SDP. 

5) The PSS server responds with RTSP 200 OK to the PSS adapter (only, if the PSS adapter has send SETUP 
messages to the PSS Server). 

6) The PSS adapter sends one SIP 200 OK to the SCF with the SDP answer containing the new media 
descriptions of RTP streams to be used. 

7) The SCF sends the SIP 200 OK to the IM CN Subsystem. The IM CN subsystem interacts with the PCRF to 
commit the reservation, and then forwards the SIP 200 OK to the UE. 

8) The UE sends the SIP ACK to the IM CN subsystem, which forwards to the SCF. The SCF forwards the SIP 
ACK to the PSS adapter. 



8.2.5.1.2 



Procedures at the UE 



To modify the session, the UE shall send a Re-INVITE or an UPDATE request as specified in TS 24.229 [7] for an 
originating UE. 

The UE shall not modify RTSP channel m-line description in the SDP if the media delivery streams controlled by RTSP 
are not removed (port not set to in the m lines) in the SDP. 

Upon receipt of a Re-INVITE request or an UPDATE request, the UE shall modify the request as specified in TS 
24.229 [7] if the request is acceptable to the UE. 
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8.2.5.1 .3 Procedures at the IM CN subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.1.4 Procedures at the SCF 

Upon receipt of a Re-INVITE request or an UPDATE request, the SCF shall follow the procedures defined in TS 
24.229 [7] concerning the AS acting as a proxy or a B2BUA. 

When receiving an SDP offer, the SCF may modify the SDP offer in accordance to the user subscription. If the SCF 
finds a media line not compatible with the user's subscription, it shall set the port of this media line to 0. If none of the 
media lines are acceptable, it shall reply with a 403 error response. 

Then the SCF forwards the Re-INVITE message to the PSS adapter. 

8.2.5.1 .5 Procedures at the PSS adapter 

Upon receipt of a Re-INVITE request or an UPDATE request, the PSS adapter shall modify the session as specified in 
TS 24.229 [7] if the request is acceptable to the PSS adapter in accordance with the user subscription. 

The PSS adapter sets up new media components, if the SDP file contains additional components. 

8.2.5.1 .6 Procedures at the PSS server 

Upon receipt of an RTSP setup, the PSS server executes the requested method and responds with an RTSP status code 
to the PSS adapter. 

8.2.5.2 PSS Content switching with available SDP, no change of media component 

and bandwidth 

8.2.5.2.1 General description 

The UE has retrieved the SDP prior to the content switching. The procedure is as described as in 3GPP TS 26.234 [8], 
with the server role being played by the PSS adapter. 
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Figure 10: IMS PSS Content switching 

NOTE: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
in response to the reception of 200 OK. 

1) The UE sends a PLAY request with the aggregated control URI of the new content to the PSS adapter. The 
PSS client adds the media control URIs of the new streams in the "Switch-Stream" header field to the RTSP 
PLAY method request as defined 3GPP TS 26.234 [8] clause 5.5.4.3. 

2) The PSS Adapter sends the RTSP PLAY message to the PSS Server. 

3) The PSS Server responses a RTSP 200 OK message to the PSS Adapter. 

4) The PSS Adapter sends the RTSP 200 OK message to UE. 

5) The PSS server delivers the switched content streams to the UE. 

6) The PSS Adapter should send a SIP INFO message to the SCF with content switching information. See clause 
8.2.5.2.5. 

The SCF may utilize the content switching information for statistic, charging etc. purpose, and may initiate a SIP Re- 
INVITE request to the UE to adjust the QoS reservation if the transport resources changed before and after switching. 



8.2.5.2.2 



Procedures at the UE 



To switch content of the PSS streaming session the UE shall send an RTSP PLAY request with the new content URI as 
defined in TS 26.234 [8] clause 5.5.4. 

8.2.5.2.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 
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8.2.5.2.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 

The SCF may also decide to change the timer value, e.g. if it is overloaded. In this case, it shall include an XML 
document in the SIP 200 OK as defined in Annex C indicating the value of this timer. If the boolean variable 
SendSwitchinglnfo is set to False, the PSS Adapter shall not send further SIP INFO messages for the life of the session. 

8.2.5.2.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message to the SCF with content switching information as defined in Annex D and Annex E. 

The SIP INFO message shall contain an XML file with the content switching information. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 
The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

8.2.5.2.6 Procedures at the PSS Server 

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4. 

8.2.5.3 PSS Content switching with available SDR, change of media components or 

QoS 

8.2.5.3.1 General Description 

Fast Content Switching as defined in 26.234 [8] Clause 5.5.4 allows also changing content when the new content 
channel requires a different number of media components as the old content channel, or when the bandwidth needs to 
be modified. 

For instance, the old content stream consists out of an audio and a video stream and the new content channel offers an 
audio, video and 3GPP Timed Text media component. Addition a media component to an ongoing stream is defined in 
26.234 [8] clause 5.5.4.6 and removing a media component in 26.234 [8] clause 5.5.4.7. 



£75/ 



3GPP TS 26.237 version 8.2.0 Release 8 



33 



ETSI TS 126 237 V8.2.0 (2009-06) 



UE 



SCF 



PSS Adapter 



PSS Server 



RTP (Old stream) 



RTSP PLAY (with Switch Stream header) 



RTSP PLAY (with Switch Stream header) 

►! 



RTSP 200 OK 



RTP (new stream, not all media components) 



SIP INFO (channel switch) 



SIP 200 OK 



RTSP 200 OK 



Re-INVITE(newSDP) 



Re-INVITE(newSDP)! 



PSS Session Modification 



SIP 200 OK 



SETUP (new flow) 



RTSP 200 OK 



SIP 200 OK 



RTSP PLAY 



RTSP PLAY 



RTSP 200 OK 



RTSP 200 OK 



RTP (new stream, all media components) 



Figure 1 1 : IMS PSS Content switching 

NOTE 1: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
in response to the reception of 200 OK. 

NOTE 2: The number of required RTSP SETUP interactions between the PSS Adapter and the PSS Server depend 
on the number of new media components in the SDP. 

The UE determines that the new SDP file contains a different number of media components as the old SDP. The UE 
updates the streaming session by sending a Re-INVITE with the new SDP file, as described in clause 8.2.3.2. The Re- 
INVITE is sent either before, during or after the RTSP PLAY switch. As soon as the UE receives the 200 OK for the 
Re-INVITE, the UE initiates a PLAY to get the new synchronization information. 



8.2.5.3.2 



Procedures at the UE 



The UE shall send an RTSP PLAY request with the new content URI as defined in TS 26.234 [8] clause 5.5.4. The UE 
changes the number of media components by sending a Re-INVITE message with the new SDP offer. After receiving 
the 200 OK for the Re-INVITE the UE initiates a PLAY to get the new synchronization information. 
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8.2.5.3.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.3.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 

The SCF may also decide to change the timer value, e.g. if it is overloaded. In this case, it shall include an XML 
document in the SIP 200 OK as defined in Annex C, indicating the value of this timer. If the boolean variable 
SendSwitchinglnfo is set to False, the PSS Adapter shall not send further SIP INFO messages for the life of the session. 

8.2.5.3.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message to the SCF with content switching information as defined in Annex D and Annex E. 

The SIP INFO message shall contain an XML file with the content switching information. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

When receiving the SIP Re-IN VITE message from the SCF, if a new media component needs to be added, the PSS 
adapter shall send the RTSP SETUP to the PSS server, indicating the new media component that needs to be added. 

8.2.5.3.6 Procedures at the PSS Server 

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4 

8.2.5.4 PSS Content switching with unavailable SDP, no change of media 

component and/or bandwidth 

8.2.5.4.1 General description 

In this case, the UE does not have the SDP for the streams it intends to switch to. The new content has same media and 
bandwidth characteristics. 
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Figure 12: IMS PSS Content switching without available SDP, no change of media component and/or 

bandwidth 

NOTE: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
in response to the reception of 200 OK. 

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS 
Adapter sends the RTSP PLAY message to the PSS Server. 

The PSS Server responses a RTSP 200 OK message to the PSS Adapter, PSS Adapter sends the RTSP 200 OK message 
to UE containing the SDP for the new streams. 

The PSS server starts streaming the switched content streams to the UE. 

The PSS Adapter should send a SIP INFO message to the SCF with content switching information according to 

clause 8.2.5.2. L 



8.2.5.4.2 



Procedures at the UE 



To switch content of the PSS streaming session the UE shall send an RTSP PLAY to request the new SDP as defined in 
TS 26.234 [8]. 

8.2.5.4.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.4.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 

The SCF may also decide to change the timer value, e.g. if it is overloaded. In this case, it shall include an XML 
document in the SIP 200 OK as defined in Annex C indicating the value of this timer. If the boolean variable 
SendSwitchinglnfo is set to False, the PSS Adapter shall not send further SIP INFO messages for the life of the session. 
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8.2.5.4.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message to the SCF with content switching information as defined in Annex D and Annex E. 

The SIP INFO message shall contain an XML file with the content switching information. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 
The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 
The PSS Adapter sends the RTSP 200 OK message to UE containing the SDP for the new stream. 

8.2.5.4.6 Procedures at the PSS Server 

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4. 

8.2.5.5 PSS Content switching with unavailable SDP, change of media component 

and/or bandwidth 

8.2.5.5.1 General description 

In this case, the UE does not have the SDP for the streams it intends to switch to. And the new content has different 
media and/or bandwidth characteristics. 
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Figure 13: IMS PSS Content switching without available SDP, 
change of media component and/or bandwidth 

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS 
Adapter sends the RTSP PLAY message to the PSS Server.. If the UE receives a "206 Partial Data" success status code, 
then the UE changes the number of media components and/or bandwidth by sending a RE-INVITE message with the 
new SDP file, as described in clause 8.2.5.1. 



8.2.5.5.2 



Procedures at the UE 



If the UE receives a "206 Partial Data" success status code, then the UE changes the number of media components by 
sending a re-INVITE message with the new SDP file. 

8.2.5.5.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.5.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 

The SCF may also decide to change the timer value, e.g. if it is overloaded. In this case, it shall include an XML 

document in the SIP 200 OK as defined in Annex C indicating the value of this timer. If the boolean variable 

Sends witchinglnfo is set to False, the PSS Adapter shall not send further SIP INFO messages for the life of the session. 
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8.2.5.5.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message to the SCF with content switching information as defined in Annex D and Annex E. 

The SIP INFO message shall contain an XML file with the content switching information. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

When receiving the SIP RE-INVITE message from the SCF, if a new media component needs to be added, the PSS 
adapter shall send the RTSP SET-UP to the PSS server, indicating the new media component that needs to be added. 

8.2.5.5.6 Procedures at the PSS Server 

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4. 

8.2.6 PSS Streaming Session Teardown 
8.2.6.0 Introduction 

Assuming the streaming session is established, the session can be terminated either by the UE or by the network. For 
the network-initiated PSS streaming session teardown, either the SCF or the PSS adapter can initiate the procedure. 
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8.2.6.1 General Description 

8.2.6.1 .1 UE-initiated PSS streaming session teardown 



UE 



SIP BYE 
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SCF 



RTP 



SIP BYE 



SIP 200 OK 



PSS Adapter 



SIP BYE 



SIP 200 OK 



PSS Server 



RTSP TEARDOWN 



RTSP 200 OK 



Figure 14a: UE-initiated IIUIS PSS Session termination 

NOTE: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
the UE in response to the reception of 200 OK 

Here the case of UE termination is described. The following steps are carried out: 

1) Note that the PSS Adapter should maintain the RTSP session to the PSS Server until after step 5. 

2) The UE sends a SIP BYE message. 

3) The IMS CN subsystem forwards the SIP BYE message to the SCF. 

4) The SCF sends the SIP BYE message to the PSS adapter. 

5) The PSS adapter sends a RTSP TEARDOWN to the PSS server. 

6) In case the PSS Server is transmitting RTP data it stops sending RTP data for this session. The PSS server 
sends a RTSP 200 OK to the PSS adapter. 

7) The PSS adapter sends a SIP 200 OK to the UE via SCF and IMS CN subsystem. 
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8.2.6.1.2 
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Figure 14b: SCF-initiated IIVIS PSS Session termination 

NOTE: this sequence is simplified and does show e.g. session progress messages. 
Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The SCF sends a SIP BYE to the PSS adapter. 

2) The PSS adapter sends the RTSP TEARDOWN message to the PSS server. 

3) The PSS server sends the RTSP 200 OK message to the PSS adapter. 

4) The PSS adapter sends the SIP 200 OK message to the SCF. 

5) Upon receipt of the SIP 200 OK, the SCF sends the SIP ACK message to the PSS adapter, and sends 
the SIP BYE message to the IM CN subsystem. 

6) The IM CN Subsystem forwards the SIP BYE message to the UE. 

7) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF. 

9) The SCF sends the SIP ACK message to the IM CN subsystem, which forwards it to the UE. 
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8.2.6.1.3 
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Figure 14c: PSS adapter-initiated IIVIS PSS Session termination 

NOTE: this sequence is simplified and does show e.g. session progress messages. 
Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The PSS adapter sends the RTSP TEARDOWN to the PSS server. 

2) The PSS server sends the RTSP 200 OK to the PSS adapter. 

3) The PSS adapter sends the SIP BYE message to the SCF. 

4) The SCF sends the SIP 200 OK message to the PSS adapter. 

5) The PSS adapter sends the SIP ACK message to the SCF. 

6) The SCF sends the SIP BYE message to the IM CN Subsystem. 

7) The IM CN Subsystem forwards the SIP BYE message to the UE. 

8) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

9) The IM CN Subsystem forwards the SIP 200 OK to the SCF. 

10) The SCF sends the SIP ACK message to the IM CN subsystem, which forwards it to the UE. 

8.2.6.2 Procedures at the UE 



8.2.6.2.1 



UE-initiated PSS streaming session teardown 



To teardown the PSS streaming session the UE shall close the TCP connection for RTSP between UE and PSS Adapter, 
if existing. Further, the UE shall send a SIP BYE to the SCF. 



8.2.6.2.2 



Networl<-initiated PSS streaming session teardown 



Upon receipt of the SIP BYE message, the UE shall the SIP 200 OK message to the SCF. The UE procedes to release 
the associated resources held for the PSS session. 
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8.2.6.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.6.4 Procedures at the SCF 

8.2.6.4.1 UE-initiated PSS streaming session teardown 
Upon receipt of a SIP BYE message the SCF shall forward it to the PSS adapter. 

8.2.6.4.2 SCF-initiated PSS streaming session teardown 

The SCF initiates the PSS streaming session teardown by sending a SIP BYE message to the PSS adapter. Upon receipt 
of the SIP 200 OK from the PSS adapter, the SCF shall send a SIP BYE message to the UE. 

8.2.6.4.3 PSS adapter-initiated PSS streaming session teardown 

Upon receipt of the SIP BYE message received from the PSS adapter, the SCF sends the SIP 200 OK message to the 
PSS adapter. Then the SCF forwards the SIP BYE message to the UE. 

8.2.6.5 Procedures at the PSS Adapter 

8.2.6.5.1 UE-initiated PSS streaming session teardown 

Upon receipt of a SIP BYE message from the SCF the PSS adapter shall send a RTSP TEARDOWN message to the 
PSS Server. 

Upon receipt of a RTSP 200 OK message from the PSS server, the PSS adapter shall send a SIP 200 OK message to the 
SCF. 

The PSS Adapter shall not close the RTSP session to the PSS Server on receipt of a TCP close, but waits until it has 
received the SIP BYE message in step 4. 

8.2.6.5.2 SCF-initiated PSS streaming session teardown 

Upon receipt of the SIP BYE message, the PSS adapter sends the RTSP TEARDOWN message to the PSS server. Upon 
receipt of the RTSP 200 OK message from the PSS server, the PSS adapter sends the SIP 200 OK to the SCF. 

8.2.6.5.3 PSS adapter-initiated PSS streaming session teardown 

The PSS adapter sends the RTSP TEARDOWN to the PSS server. Upon receipt of the RTSP 200 OK, the PSS adapter 
sends the SIP BYE messge to the SCF. 

8.2.6.6 Procedures at the PSS Server 

Upon receipt of a RTSP TEARDOWN from the PSS adapter, the PSS server shall stop still on-going RTP transmissions 
and send a RTSP 200 OK message to the PSS adapter. 

8.3 MBMS Streaming 

8.3.1 MBMS Media codecs and formats 

MBMS Media codecs and formats defined in 3GPP TS 26.346 [11] are applicable to the present document for IMS 
initiated and controlled MBMS User service. 
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8.3.2 Procedure for providing missing parameters before session 
initiation 



8.3.2.1 



Procedures at the UE 



If the UE does not have the all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS 

message. 

The "Request-URI" is related to the MBMS service that the user wants to activate. The "Request-URI" shall be 
composed of a user and domain part as defined as follows: 

The user part contains the serviceld. 

The domain part is the Service Provider domain name, obtained from SSF. 

The TO header shall contain the same URI as in the "Request-URI" parameter. 

The FROM header shall indicate the public user identity of the user. 

Upon reception of the 200 OK including service access information encapsulated in multipart/MIME, the UE shall 
initiate MBMS session as described in clause 8.3.3. 



8.3.2.2 



Procedures at the SCF 



When receiving the SIP OPTIONS message, the SCF shall examine the serviceld present in the user-part of the TO 
header and lookup the requested User Service Description information. 

The SCF shall answer with the user service description information of the content delivery channel (encapsulated in 
multipart/MIME) as requested by the serviceld. 

8.3.3 MBMS Streaming Session initiation 
8.3.3.1 General description 
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Figure 15: MBMS Streaming Session Initiation 

It is assumed that the UE has already received the MBMS USD containing the SDP and associated fragments for the 
service from the SSF before initiating the MBMS session. 

Step 1, 2: UE initiates a SIP INVITE message to SCF, indicating which MBMS Streaming User Service the 

user has chosen. 
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Step 3, 4: SCF responds UE with a SIP 200 OK message when the SIP INVITE is successfully handled. The 

SIP 200 OK contains an SDP files containing the Multicast address of the service. The UE then 
activates the MBMS bearers either using the MBMS Broadcast Service Activation procedure [4] 
or the MBMS Multicast Service Activation Procedure [4]. 

Step 5: The UE can start receiving the MBMS Streaming session data when transmitted by the BM- 

SC.UPF. 

The construction of the SDP is not affected by the use of MBMS stream bundling, see section 8.2.2 of [1 1], nor are any 
of the procedures. 

8.3.3.2 Procedures at the UE 

The UE shall support the procedures specified in TS 24 229 [7] for originating sessions. 
The UE shall generate an initial INVITE request: 

• The Request-URI in the INVITE request shall be the well known PSI (Public Service Identifier) of the MBMS 
Service. 

• The To header shall contain the same URI as in the Request-URI. 

• The From header shall indicate the public user identity of the user. 

An SDP offer shall be included in the request. The SDP offer shall be done in accordance with the parameters received 
during UE service selection procedure and with media capabilities and required bandwidth available for the MBMS 
session. The SDP offer corresponds to the MBMS Streaming Session. See 3GPP TS 26.346 [11], clause 8.3.1. . The 
SDP offer at media level shall include the following elements: 

• The m-line(s) shall be set to the media parameters retrieved via service selection procedures for the requested 
MBMS service. 

• The c-line(s) shall be set according to the multicast address retrieved via service selection procedures for the 
requested MBMS service. 

• An a=mbms_service:MBMS_ServiceId line to indicate the MBMS service which the UE intends to initiate first. 

Once the UE receives the SIP response, the UE shall examine the media parameters in the received SDP, and initiate the 
MBMS channel according to the a=mbms_service line. It can activate the corresponding MBMS User Service as 
described in the USDs. MBMS User Service reception initiation may correspond to the MBMS Broadcast Mode 
activations as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation procedure as 
described in 3GPP TS 23.246 [4], clause 8.2. 

8.3.3.3 Procedures at the IM CN Subsystem 

Once the IMS CN receives the SIP response, PCC procedures are performed as described in clause 9. 

8.3.3.4 Procedures at the SCF 

The SCF shall support the procedures specified in TS 24.229 [7] applicable to an AS acting as a terminating UA. 

Upon receipt of SIP INVITE request, the SCF shall perform service authorization procedures to check the service rights 
of requested MBMS service according to the user subscription information. See clause 10.4. 

The SCF shall examine the SDP parameters in the SDP offer. 

• It shall examine the a=mbms_service parameter. This parameter contains the channel the UE intends to 
join. If the mbms_service parameter does not point to a channel that the UE is allowed to join the SCF 
shall not accept the offer and shall answer with a 403 error code. 

• It shall examine the c-line(s) to determine that it is a multicast session. It may also check that it corresponds to 
the mbms_service parameter. If not, the SCF shall answer with an 403 error code. 

If the SDP parameters are examined successfully, the SCF shall answer with a SIP 200 OK, indicating the SDP answer 
as follows: 
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• The c-lines and m-lines shall be identical to ones indicated in the SDP offer. 

• It shall include an a=recvonly attribute. 

8.3.3.5 Procedures at the BMSC.UPF 

The MBMS session is already ongoing at the BMSC.UPF. No specific action is required. 

8.3.4 MBMS content switching 



8.3.4.1 



General Description 



It is assumed that MBMS streaming reception is already active and a stream is delivered to the UE via MBMS. In case 
of MBMS content switching, the UE tunes into a new content channel e.g. in case of MBMS multicast mode the UE 
leaves a multicast channel and joins another one. 

The UE should sent a SIP INFO Message to inform the SCF about which channel is being received unless the SCF 
prohibits it. A timer is started with a preconfigured value with default value of 10 seconds, when the channel switch is 
executed. After timer expiration the SIP INFO message is sent. 
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Figure 16: MBMS content switching 

The UE sends content switching information to the SCF. 

The content switching information may include the serviceld after switching. The SCF may utilize the content 
switching information for statistical or charging purposes etc. 



8.3.4.2 



Procedures at the UE 



The UE performs MBMS content switching according to the deactivation/activation procedures defined in [4]. 

Upon identification of a successful content switch, the UE starts the content switching timer for a particular session. If 
another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated during the 
life of the timer, the timer is stopped. After timer expiration, the UE should send a SIP INFO message as defined in 
Annex F to the SCF with content switching information. 

The SIP INFO message shall be sent by the UE on the same dialogue as the MBMS session initiation and shall contain 
an XML file with the channel switch information. 

• ImsPssMbmsCommand shall be set to "MbmsSwitch"; 

• Serviceld shall be set to the value of the new channel. If the OMA BCAST Service Guide [27] is used, this 
shall be set to Global Service ID, otherwise shall be set to the MBMS User Service Description serviceld. 

• Programmeld may be present and if present shall be set to the identifier of the current programme of the 
new channel. If the OMA BCAST Service Guide [27] is used, this shall be set to service Name. 
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• DateTime shall be set to the date & time of the channel switch. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command +xml". The body content of the 
message is described in annex D and annex F. 

8.3.4.2 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.3.4.3 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the UE. 

The SCF may also decide to change the timer value, e.g. if it is overloaded. In this case, it shall include an XML 
document in the SIP 200 OK as defined in Annex F indicating the value of this timer. If the boolean variable 
SendSwitchinglnfo is set to False, the UE shall not send further SIP INFO messages for the life of the session. 

8.3.4.4 Procedures at the BMSC.UPF 

The BMSC.UPF transmits the RTP flows, and is not involved in the reporting of content switching information. 

8.3.5 MBMS Streaming Session Teardown 
8.3.5.1 General Description 
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Figure 17: MBMS Streaming Session Termination 

UE receives Streaming content from the BM-SC.UPF. 

UE initiates a SIP BYE message to SCF, indicating which MBMS Streaming session to close. 

SCF responds UE with a SIP 200 OK message when the SIP BYE is successfully handled and 
session terminated. At this stage, the UE can stop receiving the MBMS Streaming session. 



The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5. The deactivation is 
either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS Multicast Mode 
deactivation procedure (3GPP TS 23.246 [4]). 

8.3.5.2 Procedures at the UE 

The UE shall send a SIP BYE to the SCF. 

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5 of clause 8.3.5.1. The 
deactivation is either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS 
Multicast Mode deactivation procedure (3GPP TS 23.246 [4]). 
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8.3.5.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.3.5.4 Procedures at the SCF 

The SCF responds to the UE with a SIP 200 OK message after handling of the SIP BYE message. 

8.3.5.5 Procedures at the BMSC.UPF 

The BMSC.UPF is acting as described in 3GPP TS 23.246 [4]. 

8.4 Combined PSS and MBMS Streaming 

8.4.1 Introduction 

Combined PSS and MBMS streaming is important to ensure a consistent user experience. An UE may switch between 
one and the other depending on certain circumstances, e.g. changing between a PSS and MBMS coverage etc., or 
triggered by specific user action, e.g. trick play, etc. 

It is assumed that the UE has an already established PSS or MBMS session and is capable of switching to the other 
delivery method. 

Clause 8.4.2 gives the different cases and scenarios for switching between PSS and MBMS . 

8.4.2 PSS - IVIBIVIS Switching 

In the case of hybrid PSS-MBMS switching, it is distinguished between: 

(a) switching from MBMS streaming to PSS streaming: 

• Without channel change e.g. when a user is viewing an MBMS user service and moves out of MBMS 
coverage, or the user initiates trick play mode action, etc. 

• With channel change e.g. changing to a channel only available on PSS. 

(b) switching from PSS streaming to MBMS streaming: 

• Without channel change e.g. the user returns back from trick play mode to a normal MBMS user service, etc. 

• With channel change e.g. changing to a channel available on MBMS. 

8.4.3 Switcining from MBMS streaming to PSS streaming 

According to clause 8.3.3 an MBMS streaming session was initiated and the UE is receiving the MBMS session from 
the BM-SC.UPF. 

In order to switch from MBMS to unicast reception of a stream via PSS e.g. for allowing trick play mode, a SIP Re- 
INVITE is issued by the UE. A SDP offer shall be included according to clause 8.2.3. 

After receiving the 200 OK, the UE leaves the multicast channel and starts playback. 
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Figure 18: IMS Hybrid PSS-MBMS-to-PSS content switching 



8.4.3.1 



Combined Session establishment 



8.4.3.1.1 



Procedures at the UE 



When the UE switches from an MBMS User Service to a PSS user service, the UE sends a session modification request, 
i.e. SIP re-INVITE, with a SDP Offer. 

The SDP offer shall include previously negotiated media descriptions with the port set to zero and two or more 
additional media descriptions: one for media control channel (i.e. RTSP control channel) and one or more for media 
delivery channel (i.e. delivery channel for the unicast streams). 

The RTSP control media descriptor shall follow TS 24.229 [7]. The SDP offer for media delivery shall be identical to 
the previous SDP offer done for broadcast in term of codecs and transport protocol. 

The UE may record the media offset for the MBMS user service. 

When receiving SIP 200 OK response, the UE shall setup a media control channel with the PSS Adapter, and setup a 
media delivery channel with PSS Server according to the SDP answer. The UE shall send RTSP PLAY message to start 
the delivery of the media streams. 

8.4.3.1 .2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.4.3.1.3 Procedures at the SCF 

When receiving the SIP modification request, the SCF will determine if the programme currently broadcasted has 
MBMS to PSS switching support. 
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NOTE: The SCF may determine whether the SIP modification request is for MBMS to PSS switching according 
to the addition of the RTSP media control channel or unicast media delivery channel in the SDP offer. 

If MBMS to PSS switching is not available for the UE, the session modification is rejected and the old MBMS session 
(along with the previous reserved resources) is maintained. 

If MBMS to PSS switching is available for the UE, the SCF shall act as a B2BUA, and sending a SIP INVITE request 
to the PSS Adapter with the SDP parameters for the content control channel of RTSP, and for the media delivery 
channel of unicast streams. The SCF shall precise the content identifier in the user part of the Request-URI. 
When sending the SIP INVITE message to PSS Adapter, SCF shall follow the procedures defined in TS 24.229 [7] 
concerning the AS acting as B2BUA. 

8.4.3.1 .4 Procedures at the PSS Adapter 

When receiving a SIP INVITE request from SCF, as well as receiving RTSP 200 OK message from PSS Server, the 
PSS Adapter shall conform to clause 8.2.3.5. 

Prior to replying, the PSS Adapter uses real time to calculate the media offset for the MBMS user service when replying 
with the offered media. 

When receiving RTSP message from UE, the PSS Adapter shall conform to clause 8.2.4.2. 

8.4.3.1 .5 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.4.3.2 Combined session teardown 

The combined session teardown shall conform to clause 8.2.6. 

8.4.4 Switching from PSS streaming to MBMS streaming 

According to clause 8.2.2 a PSS streaming session was initiated and the UE is receiving the PSS session from the PSS 
server. 

In order to switch from PSS to MBMS reception of a stream, a SIP Re-INVITE is issued by the UE and sent to the SCF. 
The SCF shall act as a B2BUA, and send a SIP BYE messge to PSS Adapter to terminate the SIP session between them. 
The PSS Adapter shall send a RTSP TEARDOWN messag to PSS Server to release the RTSP session. 

Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in 
the SDP as defined in clause 8.3.3.2. 

After switching to MBMS reception, the PSS session shall be terminated. 
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Figure 19: IMS PSS-to-MBMS content switching 



8.4.4.1 



Combined Session establishment 



8.4.4.1.1 



Procedures at the UE 



When the UE switches from a PSS User Service to an MBMS user service, the UE sends a session modification request, 
i.e. SIP re-INVITE, an SDP offer shall be included according to clause 8.3.3. The SDP offer for media delivery shall be 
identical to the previous SDP offer done for PSS in term of codecs and transport protocol. 

Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in 
the SDP as defined in clause 8.3.3.2. MBMS User Service reception initiation may correspond to the MBMS Broadcast 
Mode activation procedure as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation 
procedure as described in 3GPP TS 23.246 [4], clause 8.2. 

8.4.4.1 .2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 



8.4.4.1.3 



Procedures at the SCF 



When receiving the SIP modification request, the SCF will determine if the content currently delivered has PSS to 
MBMS switching support. 

If PSS to MBMS switching is not available for the UE, the session modification is rejected and the old PSS session 
(along with the previous reserved resources) is maintained. 

If PSS to MBMS switching is available for the UE, the SCF shall act as a B2BUA, and send a SIP BYE message to the 
PSS Adapter to terminate the SIP session between them. When sending the SIP BYE message to PSS Adapter, SCF 
shall follow the procedures defined in TS 24.229 [7] concerning the AS acting as B2BUA. 
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Once receiving a SIP 200 OK message from PSS Adapter, SCF sends a SIP 200 OK message to UE with a SDP answer 
as defined in clause 8.3.3.4. 

8.4.4.1 .4 Procedures at the PSS Adapter 

When receiving a SIP BYE message fi-om SCF, as well as receiving RTSP 200 OK message fi^om PSS Server, the PSS 
Adapter shall conform to clause 8.2.6.5. 

8.4.4.1 .5 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.4.4.2 Combined session teardown 

The combined session teardown shall conform to clause 8.3.5. 



Policy and charging control 



9.1 General 

For the purpose of the present specification, the policy and charging control (PCC) is according to 3GPP TS 23.203 
[12]. This clause is relevant when PCC is present. However, IMS based PSS and MBMS User Services can be realized 
without PCC. When PCC is not present, the UE is responsible for allocation of the resources based on Session 
Description information. 

Service subscription control is performed by the SCF at registration and at PSS and MBMS session initiation. 

QoS control is different for PSS and MBMS User Services. 

9.2 QoS control 

The P-CSCF is used as the Application Function in the PCC architecture. The PCRF decides how policy control of the 
QoS is performed for IMS initiated and controlled PSS and MBMS User Service. 

In case of PSS, the PCRF shall use the SDP received from the P-CSCF during session establishment to calculate the 
proper QoS authorization. The way the QoS is enforced in this architecture is defined in 3GPP TS 23.203 [12]. 

In case of MBMS, the PCRF shall not initiate the establishment of a specific bearer. 
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Figure 20: PSS QoS Policy Control 

NOTE: The sequence shown is simplified and does not e.g. show session progress messages and the ACK 
message from the UE in response to the reception of 200 OK. 

The PSS case of QoS control is shown on figure 20. The appropriate existing bearers are used or new required bearers 
are allocated. Network initiated bearer control and UE initiated bearer control are possible. When receiving the final 
SDP, the UE shall initiate the establishment of the required bearers unless a network initiated bearer allocation 
procedure is already ongoing, or the UE has been configured to use network initiated resource control. 



1 Security Procedures 



10.1 General 

Different security procedures apply for IMS, MBMS and PSS. 

IMS level authentication and access security is performed during IMS registration in accordance to [7]. 
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PSS-Only: PSS defines an optional confidentiality protection of individual RTP payloads used in a streaming session. If 
PSS confidentiality protection as defined in 3GPP TS 26.234, Annex K. is used, then the terminal initiates the 
GAA/GBA Bootstrapping procedure TS 33.220 [26] after a successful IMS registration and Service discovery. 

MBMS-only and combined PSS/MBMS service offerings: MBMS security is based on GAA/GBA [26]. The 
GAA/GBA Bootstrapping procedure is initiated by the UE after a successful IMS registration and Service discovery. It 
is necessary before any service description retrieval and session initiation. 

GBA (see 3GPP TS 33.220 [26]) is used to generate a master key Ks from which NAF specific keys (e.g. Ks_NAF for 
ME based key management) can be derived when needed. It is also used to authenticate the user for signaling that is not 
performed via the IMS core network (e.g. HTTP based service description retrieval). 

GBA is also used to generate and provision the NAF keys (e.g. Ks_NAF for ME based key management) - which is the 
Long Term Key that is used in content encryption/decryption procedures - and the B-TID - which is the corresponding 
bootstrapping transaction identifier. 
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Figure 21 : GBA/GAA Bootstrapping procedure 

Figure 21 illustrates the GBA/GAA bootstrapping procedure. The following steps are performed. See [26] for details: 

• The UE sends a request to the BSF with its IMPI as User ID. The UE discovers the address of the BSF as 
specified in [26] . 

• The BSF then acquires the User"s GUSS (GBA User Security Settings) and one Authentication Vector from 
the HSS and forwards the RAND and AUTN to the UE in the HTTP 401 message. 

• The UE checks AUTN to verify that the challenge is from an authorised network. 

• The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF. 

• The BSF authenticates the UE by verifying the Digest AKA response. The BSF shall send a 200 OK message, 
including a B-TID, to the UE to indicate the success of the authentication. 

10.2 Secure Service Description Retrieval 

The Service Description retrieval procedure allows the UE to acquire the necessary information to select and initiate 
PSS and/or MBMS sessions using IMS procedures. See clause 7 for more details on this procedure. 
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Figure 22: Service Description retrieval with authentication 

Figure 22 describes the Service Description retrieval procedure with authentication. 

The UE requesting a service description towards the SSF (acting as a NAP) shall include the B-TID corresponding to 
the Ks established during the bootstrapping procedure. When the SSF receives the service description request, it shall 
trigger an authentication request towards the BSF to acquire the NAF keys ( e.g. Ks_NAF for ME based key 
management) of the user if the SSF does not already have the NAF keys available. The SSF shall trigger HTTP digest 
authentication procedure towards the UE in accordance with 3GPP TS 33.222 [20]. 

The SSF shall use TLS to encrypt the Service Description during retrieval. 

1 0.3 PSS Authentication and Content encryption 

Void (TED). 

1 0.4 IVIBIVIS Security procedures 

The IMS based MBMS user service security procedures shall fulfil the key management procedures defined in TS 
33.246 [5], including MSKprocedures in clause 6.3.2 of TS 33.246 [5], and MTK procedures in clause 6.3.3 of TS 
33.246 [5]. The MSK procedure further includes MBMS user service registration procedure, deregistration procedure, 
MSK request procedure and MSK delivery procedure. 

Clause 10.4.1 describes MBMS security procedures where HTTP is used as described in TS 33.246 [5], and 
BMSC.UPF acts as NAF to interact with BSF and derives security keys. 

Clause 10.4.2 describes MBMS security procedures where SIP is used and SCF act as a NAF to interact with BSF and 
derives security keys. 

The procedures according to clause 10.4.1 and clause 10.4.2, respectively, are alternatives for MBMS security 
procedures. They are equal in terms of security provision. The UE shall support both alternatives for MBMS security 
procedures. The UE is informed about the supported MBMS security procedure by retrieval of the service attachment 
information from the SDF as defined in Annex H. 

1 0.4.1 HTTP based IVIBIVIS security procedure 

Clause 10.4.1 describes MSK procedures, and clause 10.4.2 describes MTK procedures. 
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10.4.1.1 MSK procedures 

The IMS based MBMS user service registration procedure, deregistation procedure, MSK request procedure and MSK 
delivery procedure are defined in clause 10.4.1 to 10.4.4 respectively. 



10.4.1.1.1 
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Figure 23: Security procedures for ilUIS based lUISIUIS user service 



10.4.1.1.1.1 Procedures at the UE 

When the user indicates to view an MBMS user service, the UE shall send a SIP INVITE message to SCF via IM CN 
Subsystem, The SIP INVITE message shall include MBMS Service ID to indicate which service the user intends to 
watch, as defined in clause 8.3.3.2, and a P- Intended -Identity header with the value set to the desired user public 
identity. 

After receiving a SIP 200 OK message, the UE shall perform MSK registration procedure as defined in clause 6.3.2.1a 
of TS 33.246[5]. The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall conform to TS 
33.246[5], and include an HTTP X-3GPP- Intended -Identity header as defined in TS 24.109 [22] with the value set to 
the user"s public identity. 

10.4.1.1.1.2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

10.4.1.1.1.3 Procedures at the SCF 

Upon receipt of a SIP INVITE request, the SCF shall perform service authorization procedure as defined in clause 

8.3.3.4. 

After successfully service authorization, the SCF shall send an Authorization Notification HTTP POST message to 
BMSC.UPF. The HTTP POST message shall be populated as follows: 

the HTTP version shall be 1.1 which is specified in RFC2616; 
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the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "authorize", i.e. Request-URI 
takes the form of "/keymanagement?requesttype= authorize"; 

- the HTTP X-3GPP-Asserted-Identity header shall be the IMPU of the user retrieved from the SIP INVITE 
message. 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-authorize-nxml". 

the HTTP payload shall contain request including the authorized MBMS Service ID Serviceld carried in the SIP 
INVITE message; 

After receiving an authorization acknowledgement, the SCF shall send a SIP 200 OK message to the UE as defined in 
clause 8.3.3.4. 

10.4.1 .1 .1 .4 Procedures at the BM-SC. UPF 

Upon receiving an Authorization Notification message from SCF, the BMSC.UPF shall store the received message, and 
respond an Authorization Acknowledgment HTTP 200 OK message. 

Upon receiving MSK registration message from a UE, the BMSC.UPF shall act as a NAF and perform GBA usage 
procedure with BSF to get GBA keys to derive MUK. The MUK is used for BM-SC.UPF to protect the transfer of 
MSK. 

The BMSC.UPF shall authorize the UE according to the stored information. The BMSC.UPF shall send MSKs to the 
UE corresponding to the service IDs in the received message via MIKEY, as defined in clause 6.3.2.1a of TS 33.246[5]. 

1 0.4.1 .1 .2 IMS based MBMS user service key deregistration procedure 

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2. IB of TS 33.246[5]. Additionaly, 
The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended - 
Identity header as defined in TS 24.109 [22] with the value set to the user"s public identity. 

1 0.4.1 .1 .3 IMS based MBMS user service MSK request procedure 

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2.2 of TS 33.246[5]. Additionaly, 
The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended - 
Identity header as defined in TS 24.109 [22] with the value set to the user"s public identity. 

1 0.4.1 .1 .4 IMS based MBMS user service MSK delivery procedure 

The IMS based MBMS user service MSK delivery procedure conforms to clause 6.3.2.3 of TS 33.246[5]. 

10.4.1.2 MTK procedure 

The IMS based MBMS user service MTK procedure conforms to clause 6.3.3 of TS 33.246[5]. 

1 0.4.2 SIP based MBMS security procedures 
10.4.2.0 General 

Clause 10.4.2 describes an alternative to clause 10.4.1 for MBMS security procedures, where the NAF for the MBMS 
User Services is implemented in the SCF and interacts with the BSF. The procedures apply for both ME and UICC 
based key management. 

The MBMS Security specification 3GPP TS 33.246 [5] defines a set of security procedures. The following list 
describes how these procedures are applied in the context of IMS based MBMS user services when using SIP based 
MBMS security procedures. 

'MBMS User Service Registration procedure'. 
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In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 

10.4.2.1 in the present document. 

'MBMS User Service Deregistration procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 
10.4.2. 1 A in the present document. 

'Basic MSK request procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 

10.4.2.2 in the present document. 

'Missed key update procedure'. 

This procedure is equivalent to Basic MSK request procedure. 

'BM-SC solicited pull procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 
10.4.2.4 in the present document. 

- 'MSK delivery procedure' 

In the context of SIP based MBMS security procedure, this procedure is applied as defined TS 33.246 [5] 
with exception that SCF FQDN is sent instead of BM-SC FQDN. 

'MTK update procedure' 

In the context of SIP based MBMS user services this procedure is applied as defined TS 33.246 [5]. 



10.4.2.1 SIP based MBMS User Service Registration 

This procedure is used to register a UE with one or more MBMS User Services. 

It is assumed that the UE has received the service description (cf clause 10.2). The service description includes, e.g. 
the service protection description. The service protection description is similar as defined in 3GPP TS 33.246 with the 
following exception: the FQDN of the BM-SC is not included in the service protection description. Instead, the service 
protection description for the service shall include an FQDN belonging to the SCF as the SCF acts as a NAF. 

NOTE 1 : This is to ensure consistent NAF key derivation in the UE and in the BSE as the SCF acts as a NAF and 
as the FQDN of the NAF is used as input in NAF key derivation. 

In case more than one BM-SCs are connected to the SCF, the SCF shall locally associate a different one of its FQDNs 
to each connected BM-SC. As there is one NAF FQDN indicated in the service protection description for each service, 
the SCF (NAF) will know from the userServiceld indicated by the UE which NAF FQDN to be used for NAF key 
derivation. 

NOTE 2: This will ensure that each connected BM-SC will get different NAF key, and consequently will get 
different MUK. GB A TS 33.220 allows the NAF to be known in DNS under several FQDNs if it is 
ensured that the correct NAF FQDN is used in NAF key derivation. 

It is also assumed that the UE has been registered and authenticated to IMS and the SIP procedures are protected 
according to 3GPP TS 33.203 [31], and that the UE has run GBA bootstrapping with the BSE as defined in 3GPP TS 
33.220 [26]. It is also assumed that the network interfaces are protected with Network Domain Security (NDS/IP) as 
defined in 3GPP TS 33.210 [32]. 
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Figure 24: SIP based MBMS User Service Registration 

The procedure is as follows (cf. figure 24 which is simplified as it does not show all parameters): 

- The UE sends a SIP INVITE to the SCF via the IM CN subsystem. The INVITE indicates SCF in the Request- 
URI and the message includes the identities of the requested MBMS user services (userServicelds) for which the 
UE wants to register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The 
XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the 
B-TID is defined in annex x.l. 

The SCF receives the IP address of the UE and the asserted identitie(s) of the UE from the headers of the SIP 
INVITE message. The SCF performs a check based on stored subscription information whether the UE is 
authorized to access the requested MBMS user services. If yes, the procedure continues. If not, the procedure is 
terminated. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated in the 
service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 
[26]. As there is one NAF FQDN indicated in the service protection description for each service, the SCF will 
know from the userServiceld indicated by the UE which FQDN to be used as NAF FQDN. Upon receiving the 
NAF keys from the BSF, the SCF derives MBMS User Key (MUK) as defined in TS 33.246 [5]. 
If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping, 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 
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the HTTP version shall be 1.1 which is specified in RFC 2616; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-register", i.e. 
Request-URI takes the form of "/keymanagement?requesttype= sip-based-register "; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identitie(s) of the UE; 

the HTTP header Content-Type shall be the MIME type of the payloads; 

the HTTP payload shall contain an XML document including a list of one or more userServicelds of MBMS 
User Services to which the UE wants to register, IP address of the UE, MBMS user key (MUK), lifetime of 
MUK, NAP FQDN and B-TID. NAF FQDN and B-TID are included as they are further included in the 
MIKEY MSK messages from the BM-SC to the UE to identify the used MUK (i.e. NAF key). The XML 
schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for carrying 
IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2. 

- the SCF may add additional HTTP headers to the HTTP POST request. 

Upon receiving the HTTP POST message, the BM-SC checks that the HTTP POST is valid, and extracts the 
request for further processing. As the HTTP POST message came from SCF with asserted identitie(s), the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST 
message also implicitly indicates to the BM-SC that the SCF has authorized the UE to register to the indicated 
MBMS User Service(s). 

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate 
HTTP response as follows: 

- the HTTP status code in the HTTP status Une shall be 200; 

- the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register- 
response-Hxml "; 

the HTTP payload shall contain an XML document including a list including one status code for each MBMS 
User Service. The XML schema of the payload is the same that is used for MBMS Registration in TS 33.246 
[5] and it is specified in TS 26.346 [11]. 

- Upon receiving the HTTP 200 OK., the SCF then includes the XML body from the HTTP 200 OK message into 
a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 

Upon receiving the 200 OK the UE derives NAF keys corresponding to the NAF-Id. The NAF-Id is constructed 
from the NAF FQDN indicated in the service description and Ua security protocol identifier specified in 3GPP 
TS 33.220 [26]. The UE derives MBMS User Key (MUK) from the NAF key as defined in TS 33.246 [5]. 

BM-SC can now start sending MIKEY MSK messages (protected with MUK) to the UE as defined in TS 33.246 [5]. In 
MIKEY MSK messages the BM-SC shall include the NAF FQDN and B-TID received from the SCF as they are used to 
identify the used MUK (i.e. NAF keys). 

10.4.2.1a SIP based MBMS User Service De-registration 

This procedure is used to de-register a UE from one or more MBMS User Services. 

The same assumptions apply as in SIP based MBMS User Service Registration in clause 10.4.2.1. 
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Figure 24a: SIP based MBMS User Service De-registration 

The procedure is as follows (cf. figure 24a which is simplified as it does not show all parameters): 

- UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request- 
URI and the message includes the identities of the requested MBMS user services (userServicelds) from which 
the UE wants to de-register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE.. 
The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for 
the B-TID is defined in annex x. 1. 

The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in TS 33.220 [26]. The NAF-Id which the SCF uses over Zn constructed from the NAF FQDN indicated in the 
service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 
[26]. Upon receiving the NAF key from the BSF, the SCF derives MBMS User Key (MUK) as defined in TS 
33.246 [5]. 

If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping. 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 

the HTTP version shall be 1.1 which is specified in RFC 2616; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-deregister", i.e. 
Request-URI takes the form of "keymanagement?requesttype= sip-based-deregister"; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identities of the UE; 

- the HTTP header Content-Type shall be the MIME type of the payloads; 
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the HTTP payload shall contain the request an XML document including a list of one or more userServicelds 
of MBMS User Services from which the UE wants to deregister. If new N AF keys were created in the 
previous step, then the SCF shall also include MBMS user key (MUK), lifetime of MUK, NAP FQDN and 
B-TID. E.g. the BM-SC may send an MSK message to invalidate the MSKs in the UE as defined in TS 
33.246 [5]. The XML schema for the Ust of MBMS user service IDs is defined in TS 26.346 [11] and the 
XML schema for carrying MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2; 

- the SCF may add additional HTTP headers to the HTTP POST request. 

- The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is vahd, and extracts 
the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. 

The BM-SC returns HTTP 200 OK to the SCF. The BM-SC shall populate HTTP response as follows: 

- the HTTP status code in the HTTP status Une shall be 200; 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register- 
response-Hxml". XML document is the same that is used for MBMS De-registration in TS 33.246 [5] and it is 
specified in TS 26.346 [11]; 

the HTTP payload shall contain a list including one status code for each MBMS User Service. 

- Upon receiving the HTTP 200 OK, the SCF then includes the XML body from the HTTP 200 OK message into a 
SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 

10.4.2.2 SIP based Basic MSK Request 

This procedure is used to by the UE to request one or more MSKs. 
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Figure 25: SIP based MBMS MSK request 

The same assumptions apply as in IMS based MBMS User Service Registration in clause 10.4.2.1. 

The procedure is as follows (cf figure 25 which is simplified as it does not show all parameters): 

- UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request- 
URI and the message includes a list of one or more Key Domain ID - MSK ID pair(s) of the MSKs that the UE 
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wants to receive and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The XML 
schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the B-TID 
is defined in annex x. 1 . 

The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message. The SCF 
performs a check based on stored subscription information whether the UE is authorized to receive the specified 
MSK(s). If yes, the procedure continues. If not, the procedure is terminated. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated in the 
service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 
[26]. Upon receiving the NAF keys from the BSF, the SCF derives MUK from the NAF key as defined in TS 
33.246 [5]. 

If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping. 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 

the HTTP version shall be 1.1 which is specified in RFC 2616; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-msk-request", 
i.e. Request-URI takes the form of "/keymanagement?requesttype= sip-based-msk-request"; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identities of the UE; 

the HTTP header Content-Type shall be the MIME type of the payloads; 

the HTTP payload shall contain a list of one or more Key Domain ID - MSK ID pair(s) of the MSKs that the 
UE wants to receive. If new NAF keys were created in the previous step, then the SCF shall also include 
MBMS user key (MUK), lifetime of MUK, NAF FQDN and B-TID. NAF FQDN and B-TID are included as 
they may be further included in the MIKEY MSK messages from the BM-SC to the UE, The XML schema 
for the Hst of Key Domain ID - MSK ID pair(s) is defined in TS 26.346 [11] and the XML schema for 
carrying IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2. 

the UE may add additional HTTP headers to the HTTP POST request. 

- The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is vaHd, and extracts 
the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST 
message also implicitly indicates to the BM-SC that the SCF has authorized the UE to receive the specified 
MSK(s). 

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate 
HTTP response as follows: 

- the HTTP status code in the HTTP status line shall be 200; 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-msk- 
response-Hxml" ; 

the HTTP payload shall contain a list including one status code for each MSK. The XML schema of the 
payload is the same that is used for MBMS MSK request in TS 33.246 [5] and it is specified in TS 26.346 
[11]. 

- The SCF receives the HTTP 200 OK. The SCF then includes the XML body from the HTTP 200 OK message 
into a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 
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10.4.2.3 Updating MUK 

The GBA session (i.e. key Ks derived NAF specific keys, e.g. MUK) has a limited lifetime. The GBA session may 
expire during service consumption. In this case the UE shall run GBA bootstrapping again to create a new Ks. The UE 
shall then re-register to the services with the SIP based MBMS registration procedure defined in clause 10.4.2.1 with re- 
INVITE and the new B-TID. This will create a new MUK in the UE and network. 

1 0.4.2.4 SIP based BM-SC solicited pull 

According to 3GPP TS 33.246 BM-SC solicited pull procedure is triggered by the BM-SC by sending an MSK message 
with a specific MSK-ID value. This will trigger the UE to perform MSK request. IMS based MBMS uses the BM-SC 
solicited pull procedure as defined in TS 33.246 to trigger the UE to perform SIP based basic MSK request procedure 
which is specified in clause 10.4.2.2. 
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Annex A (normative): 
3gpp_rtsp application 



The 3gpp_rtsp application defines a set of RTSP parameters. An RTSP parameter is included in "a=fmtp" line of the 
SDP and is expressed in the form of parameter=value. 

a=fmtp : 3gpp_rtsp <parameter name>=<value> 

The "version" parameter sets the "version-number" representing the version of RTSP that will be used in the RTSP 
media stream. The version number shall be "1.0" in this version of the specification. The RTSP version shall be 
included in all SDP offers and answers. The same version shall be used by all entities. 

a=fmtp : 3gpp_rtsp version=<version-number> 

To exchange RTSP header fields within the SIP offer/answer, the RTSP media stream allows for attributes with the 
following format: 

a=fmtp : 3gpp_rtsp h-<header- name >=<header- value >, 

where "header-name" is the name of the RTSP header field being described and "header-value" is the value of the RTSP 
header field. The value of the header-name is case insensitive. The value of the header- value is interpreted according to 
the rules of RTSP. The list of authorized headers in the SIP offer/answer is as follows: 

• Session: this is the RTSP session id as established by the PSS adapter to be used for further RTSP transactions. 

• Offset: this is a range value to be used in the first PLAY request by the UE. 

• Supported" header filed with the following feature tags (see 3GPP TS 26.234 [8]): 

"3gpp-switch" feature-tag, clause 5.5.4.2. 
"3gpp-switch-req-sdp" feature-tag, clause 5.5.4.3. 
"3gpp-switch-stream" feature-tag, clause 5.5.4.4. 

• Require (see 3GPP TS 26.234 [8]). 

• Pipelined-Requests (see 3GPP TS 26.234 [8]). 

• 3GPP-Adaptation (see 3GPP TS 26.234 [8]). 

UE, PSS Servers and PSS adapters shall support all these headers and feature tags. 
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Annex B (informative): 
Examples 

Void (TBD). 
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Annex C (normative): 

XML Schema for timer modification 

This XML Schema defines the timer modification signalled by the SCF within the body of SIP 200 OK response. 
This XML may be included by the SCF: 

- For PSS, in the SIP 200 OK response to the SIP INFO message sent after PSS Content Switching 

- For MBMS, in the SIP 200 OK response to either the SIP INVITE of the MBMS Streaming session set-up, or the 
SIP INFO message sent by the UE after MBMS Content Switching. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema 

targetNamespace="urn:3GPP:metadata:2008 : IMS -PSS -MBMS iTimerModif" 

xmlns :xs = "http: //www.w3 . org/2 1/XMLSchema" 

elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 

<xs : annotation> 

<xs : documentation xml : lang="en" > 
Indicates modification of the timer value for content switching information reported to the SCF 
</xs : documentation> 
</xs : annotation> 

<xs:element name="Timer" type="xs : restriction"/> 
<xs : restriction base="xs : integer" > 

<xs iminLength value="0"/> 

<xs imaxLength value="3600"/> 
</xs : restriction> 

<xs : simpleType name="SendSwitchingInfo" > 
<xs : restriction base="xs : boolean" /> 
</xs : simpleType> 

</xs : schema> 
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Annex D (normative): 

XML Schema for PSS and MBMS commands 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 001/XMLSchema" 

xmlns :pss="urn:org: etsi :ngn:params :xml : ns : PssContentSwitchData" 

xmlns :mbms="urn:org: etsi :ngn:params :xml :ns iMbmsContentSwitchData" 

xmlns : local="urn:org: etsi :ngn:params :xml :ns : PssMbmscommand" 

targetNamespace="urn:org: etsi mgmparams :xml :ns : PssMbmscommand" elementFormDefault = " qualified" 

attributeFormDefault=" unqualified" > 

<xs : import namespace="urn : org : etsi mgmparams :xml :ns : PssContentSwitchData" 
schemaLocation="PssSwitchData.xsd"/> 

<xs : import namespace="urn:org: etsi mgmparams :xml ms iMbmsContentSwitchData" 
schemaLocation="MbmsSwitchData .xsd"/> 

<xs : element name="ImsPssMbmsCommand" > 
<xs : complexType> 
<xs : choice> 

<xs:element name="PssSwitch" type="local : tPssSwitch" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

<xs: element name="MbmsSwitch" type= " local : tMbmsSwitch" minOccurs="0" 
maxOccur s = " unbounded " / > 
</xs : choice> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tPssSwitch" > 
<xs : choice> 

<xs : element ref ="pss : PssSwitchData"/> 
</xs : choice> 
</xs : complexType> 

<xs : complexType name=" tMbmsSwitch" > 
<xs : choice> 

<xs : element ref ="mbms :MbmsSwitchData"/> 
</xs : choice> 
</xs : complexType> 
</xs : schema> 
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Annex E (normative): 

XML Schemas for the PSS content switch data 

This annex specifies XML schemas for PSS content switch data: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2001/XMLSchema" 

xmlns="urn:org: etsi :ngn:params :xml :ns : PssContentSwitchData" 

targetNamespace="urn:org: etsi :ngn:params :xml :ns : PssContentSwitchData" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : element name="PssSwitchData" > 

<xs : complexType> 
<xs : sequence> 
<xs:element name="ContentID" type="xs : string" minOccurs="0"/> 
<xs:element name="DateTime" type="xs idateTime" minOccurs=" 0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence > 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tExtension" > 
<xs : sequence> 
<xs : any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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Annex F (normative): XML Schemas for the MBMS content 
switch data 

This annex specifies XML schemas for MBMS content switch data: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn:org: etsi :ngn:params :xml :ns iMbmsContentSwitchData" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn:org: etsi :ngn:params :xml :ns iMbmsContentSwitchData" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="MbmsSwitchData" > 
<xs : complexType> 

<xs : sequence> 

<xs: element name="ServiceId" type="xs : string" minOccurs="0"/> 
<xs: element name="ProgrammeId" type="xs : string" minOccurs="0"/> 
<xs:element name="DateTime" type="xs :dateTime" minOccurs="0"/> 
<xs: element name=" Extension" type="tExtension" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : complexType name="tExtension" > 
<xs : sequence> 
<xs : any processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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Annex G (normative): 

XML Schema for PSS and MBMS UE Device Capabilities 

This XML Schema defines the UE device capabilities that are signalled by the UE within the body of the SIP 
SUBSCRIBE request when attaching to the service. Another document is also part of the body to describe PSS 
Capabilities as defined in TS 26.234. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema 

targetNamespace="urn:3GPP:metadata:2008 : IMS -PSS -MBMS lUECap" 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault=" qualified" attributeFormDefault= "unqualified" > 

<xs : annotation> 

<xs : documentation xml : lang="en"> 
Defines the capabilities of the UE that is currently associated with the user 
</xs : documentation> 
</xs : annotation> 

<xs:element name="UEInformation" type="tUEProf ile"/> 
<xs : complexType name="tUEProf ile" > 
<xs : sequence> 

<xs: element name="UserEquipmentModelName" type="xs : string"/> 
<xs : element name="UserEquipmentModelVersion" type="xs : string"/> 
<xs:element name="UserEquipmentID" type=" tUEID"/> 

<xs : element name ="UserEquipment Class" type="tUserEquipmentClass"/> 
<xs : element name="UserEquipmentMBMSCapable" type="xs : boolean" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tUEID" final="list restriction" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >User Equipment ID</label> 
<definition xml : lang="en" >Unique Identifier for the UE{eg;Could be MAC address of UE) 
</def inition> 

</xs : documentation> 
</xs : annotation> 

<xs : restriction base="xs : string" > 
<xs iminLength value="0"/> 
<xs imaxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tUserEquipmentClass" final="list restriction" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >User Equipment class</label> 
<definition xml : lang="en" >Specif ies the type of UE</def inition> 

</xs : documentation> 
</xs : annotation> 
<xs : restriction base="xs : string" > 

<xs : enumeration value="STB"> </xs : enumeration> 

<xs : enumeration value="PC"> </xs : enumeration> 

<xs : enumeration value="Handset" > </xs : enumeration> 
</xs :restriction> 
</xs : simpleType> 
</xs : schema> 
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Annex H (normative): 

XML Schema for Service Attachment Information 

This annex describes the XML schema for the service attachment information to be returned to UE by SDF. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs: element name="SSF" type="tSSF"> 

<xs : annotation> 

<xs :documentation>XML Body of the SDF SIP Notify Response</xs : documentation> 

</xs : annotation> 
</xs : element> 

<xs : complexType name="tSSF"> 
<xs : sequence> 

<xs:element name="Description" type="tMultilingual" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

<xs: element name="ServiceProvider" type="tSSFServiceProvider" minOccurs=" 0"/> 
<xs:element name="Pull" type="tSSFPull" minOccurs="0" maxOccurs= "unbounded" /> 
<xs:element name="Push" type="tSSFPush" minOccurs="0" maxOccurs="unbounded"/> 
<xs:element name="MBMSSecurityProcedure" type="tMBMSSec" minOccurs="0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="ID" type="tHexadecimall6bit" use="required"/> 
<xs : attribute name=" Technology" type="xs : string" use="required"/> 
<xs : attribute name= "Version" type="tVersion" > 
<xs : annotation> 

<xs :documentation>The version number is incremented when one or more attributes of 
the SSF element have changed, so that the receiver knows whether it should update its data or 
not . </xs : documentation> 

</xs : annotation> 
</xs : attribute> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

<xs : simpleType name="tVersion" > 

<xs : restriction base="xs : integer" > 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="255"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="tSSFServiceProvider" > 
<xs : sequence> 

<xs:element name="Name" type="tMultilingual" maxOccurs="unbounded"/> 
<xs:element name="Description" type="tMultilingual" minOccurs="0" 
maxOccur s = " unbounded " / > 

<xs:element name=" Extension" type="tExtension" minOccurs=" 0"/> 
</xs : sequence> 

<xs : attribute name="DomainName" type="tDomain" use= " required" > 
<xs : annotation> 

<xs :documentation>It is recommended that the DomainName complies with the "preferred 
name syntax" of RFC1034 clause 3 . 5</xs :documentation> 
</xs : annotation> 
</xs : attribute> 

<xs : attribute name="LogoURI" type="xs : anyURI" use="optional"/> 
<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

<xs : simpleType name="tDomain" > 

<xs : restriction base="xs : string" > 

<xs: pattern value=" {{. |\n|\r)*)?{\. {. |\n|\r)*)+"/> 

</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="tSSFPull" > 
<xs : complexContent> 

<xs : extension base="tDataTypeList" > 

<xs : attribute name="Location" type="xs : anyURI" use="required"/> 
<xs : anyAttribute namespace="##other" processContents="lax" > 
<xs : annotation> 
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<xs :documentation>Extension attribute to define further 
data</xs : documentation> 

</xs : annotation> 
</xs : anyAttribute> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : complexType name="tSSFPush" > 
<xs : complexContent> 

<xs : extension base="tDataTypeList" > 

<xs : attribute name="IpVersion" type="tVersion" use="optional"/> 
<xs : attribute name="MulticastAddress" type="xs : string" use="required"/> 
<xs : attribute name="MulticastPort" type="xs lunsignedShort" use=" required" /> 
<xs : attribute name="SourceAddress" type="xs : string" use="optional"/> 
<xs : anyAttribute namespace="##other" processContents="lax" > 
<xs : annotation> 

<xs :documentation> Extension attribute to define further data 
></xs : documentation> 

</xs : annotation> 
</xs : anyAttribute > 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : complexType name="tDataTypeList" > 
<xs : sequence maxOccurs="unbounded" > 
<xs: element name="DataType" > 
<xs : complexType > 

<xs : sequence minOccurs="0" maxOccurs= "unbounded" > 
<xs: element name= " Segment " > 
<xs : annotation> 

<xs :documentation>Segments are used to logically separate Service 
Selection inf ormation</xs : documentation> 

</xs : annotation> 
<xs : complexType> 

<xs : attribute name="ID" type="tHexadecimall6bit" use="required"/> 
<xs : attribute name= "Version" type="tVersion" use="optional"/> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 

<xs : attribute name="Type" type="tHexadecimal8bit" use="required" > 
<xs : annotation> 

<xs :documentation> Specify the type of Service Selection Information 
that is delivered by the SSF 

</xs : documentation> 

</xs : annotation> 
</xs : attribute> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="tExtension" > 

<xs : sequence> 

<xs : any processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

<xs : complexType name="tMultilingual" > 
<xs : simpleContent> 

<xs : extension base="xs : string" > 

<xs : attribute name=" Language" type="tLanguage" use="required"/> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType > 

<xs : simpleType name="tLanguage" > 

<xs : restriction base="xs : string" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang="en" >ISO 639-2 Language code</def inition> 
</xs : documentation> 
</xs : annotation> 
<xs iminLength value="3"/> 
<xs imaxLength value="3"/> 
</xs : restriction> 
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</xs : simpleType> 

<xs : simpleType name="tHexadecimal8bit" > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,2}"/> 
</xs : restriction> 

</xs : simpleType> 

<xs : simpleType name="tHexadecimall6bit" > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,4}"/> 
</xs : restriction> 

</xs : simpleType> 

<xs : simpleType name="tMBMSSec" > 

<xs : restriction base="xs : string" > 
<xs : enumeration value="SIP"/> 
<xs : enumeration value="HTTP"/> 
</xs : restriction> 
</xs : simpleType> 

</xs : schema> 
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Annex I (normative): 

XML Schemas for SIP based MBMS security procedures 

1.1 Bootstrapping transaction identifier 

The following specifies XML schema for the bootstrapping transaction identifier to be sent within the body of SIP (re- 
)INVITE from the UE to the SCF. 

<?xml version="l. 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 1/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2 005 :MBMS ibootstrappingTransactionldentif ier" 
elementFormDefault= "qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsAuthorizedSecurityRegister" > 
<xs : annotation> 

<xs :documentation>MBMS Security Registration according to TS 26 . 237</xs :documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="btid" type="xs : string" maxOccurs="unbounded" minOccurs="l"/> 
<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
processContents= " lax" /> 
</xs : sequence> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element> 
</xs : schema> 



1.2 NAF key information 



The following specifies XML schema for the UE and NAF key related information to be sent within the body of HTTP 
request from the SCF to the BM-SC. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.wS . org/2 001/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS mafKeylnfo" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsAuthorizedSecurityRegister" > 
<xs : annotation> 

<xs :documentation> SIP based MBMS Security Registration according to TS 
26 . 237</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="ueIPaddress" type="xs : anyURI" maxOccurs="unbounded" 
minOccurs=" 0"/> 

<xs:element name="muk" type="xs : anyURI" maxOccurs="unbounded" minOccurs="l"/> 
<xs:element name="mukLif eTime " type="xs : anyURI" maxOccurs="unbounded" 
minOccurs= " 1 " / > 

<xs:element name="btid" type="xs : string" maxOccurs="unbounded" minOccurs="l"/> 
<xs:element name="naf Fqdn" type="xs :base64Binary" maxOccurs="unbounded" 
minOccurs= " 1 " / > 

<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
processContents="lax"/> 
</xs : sequence > 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element > 
</xs : schema> 
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